System and method for managing organizations

ABSTRACT

A system and method for managing business organizations. A database management system establishes a database, the database including a plurality of database records, each record including values, at a given point in time and for a respective business organization, of some or all of quantitative data associated with financial risk. The database management system establishes a database, the database including a plurality of database records, each database record associated with one of a plurality of separate business organizations, each record including values, at a given point in time and for the respective business organization, of some or all of the quantitative data associated with financial risk. The records are applied to a financial risk prediction model to assess financial risk for the business organization.

RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.13/965,824, filed Aug. 13, 2013, which is a continuation of U.S.application Ser. No. 12/359,108, filed Jan. 23, 2009, now U.S. Pat. No.8,515,804, both of which patent applications are incorporated herein byreference in their entirety. This application claims priority to, andincorporates by reference under 35 U.S.C. Section 119(e), U.S.Provisional Patent Application Ser. No. 61/023,039, filed Jan. 23, 2008.

TECHNICAL FIELD

The present invention is related to software, and more particularly to asystem and method for assessing organizations.

BACKGROUND

It is critical for an organization that relies on partner organizationsto ensure that its partners have capabilities in place to consistentlymeet the organization's objectives. Organizations that rely on manypartners include:

-   -   Product manufacturers with large supply chains that provide raw        materials, components and outsourced production services;    -   Businesses that rely on other organizations substantially for        sales and distribution services;    -   Government organizations that rely on a network of external        partners that deliver related products and services to address        constituent needs; and    -   An association that is tasked with helping its member        organizations to improve their capabilities in certain domains        (e.g. quality, environment) and to help members communicate        selected capability facts to their customers. In this situation,        the members are the partner organizations and the association is        the organizing party.

Large organizations often rely on many dozens, hundreds or thousands ofpartner organizations. Many of an organization's partners can expose theorganization to significant risk of damage to brand value, stock value,customer satisfaction, revenue, and stock value. For example, partnerscan damage an organization through (1) violations of governmentregulations, laws or the organization's policies; (2) unplanneddisruptions to products and services required for production, sales anddistribution; and (3) deterioration in the quality or delivery ofpartner products or services.

First, partner violations of government regulations, laws or theorganization's policies can cause an organization's own products to bein violation.

For example, a manufacturer may include components from a supplier thathas inadequate internal controls leading to:

-   -   Use of hazardous, toxic or regulated chemicals    -   Inaccurate country of origin labeling    -   Violations of labor laws    -   Violations of the organization's policies for labor, environment        and social responsibility

Second, unplanned disruptions to products and services required forproduction, sales and distribution can cause significant financialhardships and customer satisfaction issues for an organization. Forexample:

-   -   Manufacture of key products may be stopped if a key component is        unavailable. Some such outages can be avoided with adequate        planning capabilities. For instance, a supplier outage may be        caused by a disaster event striking suppliers who prepared        poorly for such events. This can result in a large shortfall in        revenue and profit for the organization.    -   Customer satisfaction may drop if an outsourced customer service        call center provides poor or inconsistent support experiences        for customers    -   A significant revenue and profit shortfall may occur if an        outsourced sales call center is suddenly unavailable at the end        of a quarter due to an Information Technology (IT) outage and        poor planning for alternative procedures.

Third, deterioration in the quality or delivery of partner products orservices can cause quality problems in an organization's products andservices. For example, a supplier may suffer quality problems forvarious reasons (e.g. inadequate internal controls of productionprocesses; inadequate procedures to contain contamination by chemicalspills). The resulting poor quality components may be integrated intoorganization products. As a result, the products may significantlyunderperform or contain dangerous chemicals.

The examples above showed how poorly managed partner capabilities posesignificant risks to an organization. On the other end of the spectrum,strengthening partner capabilities can help an organization to competebetter. For example:

-   -   A business whose partners have sound disaster planning in place        when a regional disaster strikes, may be able to gain market        share on competitors whose partners were more impacted by the        same disaster event    -   An association that is effective in helping its member        organizations to improve their capabilities in a domain        demonstrates value and is more likely to retain and grow its        members.

Organizations with a large number of partners tend to be the mostvulnerable to partner risks. The reason is that the more partners thereare, the more potential negative events that can inflict damage to anorganization's brand value, stock value, customer satisfaction andrevenue. Therefore, organizations with many 20 partners take great riskif they manage only their top partners. The capabilities of all partnersmust be managed since all partners are sources of risk. However,managing the capabilities of all partners is especially difficult fororganizations with many dozens, hundreds or thousands of partners.

Organizations generally use one or more of the following approaches toensure that partners have adequate capabilities:

-   -   Mass communication to all partners    -   Partner data gathering    -   Personal capability reviews with top partners only

First, organizations use mass communications to inform partners aboutcapability expectations. Mail, email and websites may be used to informpartners that they are expected to have certain capabilities in place,such as the ability to manage their risks and quality effectively andmay offer templates, samples and instructions intended to help partnersunderstand the capability objectives. The advantage of masscommunication is that it is inexpensive. However, mass communication:

-   -   Is ineffective at producing mass improvements. Mass        communication only informs the partners. Few improvements are        likely without follow-up:    -   Leaves the organization unaware of risks and partner        capabilities since it does not gather data.

Second, organizations may gather data from partner organizations. Forexample, in one embodiment, an organization uses electronic surveys toget data about current partner capabilities. The main advantage ofelectronic surveys is that they are inexpensive and configurable. On theother hand, such surveys do not provide a system for managing partnercapabilities to achieve capability objectives. They simply help togather data about current capabilities.

Third, organizations perform personal capability reviews focused on toppartners only after gathering data from the top partners. The advantageof personal capability reviews is that they allow an organization toidentify and communicate gaps to top partners. The disadvantages are:

-   -   Manually intensive review. They are manually intensive and        therefore organizations do not have the resources to apply        detailed reviews to more than the top partners (e.g. the top        10-50 suppliers in the supply chain or the top channel sales        partners).    -   Manually intensive follow-up. Effective follow-up requires        up-to-date records on supplier gap status, supplier contact        persons and supplier type. This makes effective follow-up        ill-suited to a manual process.    -   Lack of visibility across partners. For example, to answer a        question like which partners have a particular gap, an        organization would need to open all the files that all the        partners sent. Partners often provide multiple files in response        to capability surveys. As a result, an organization with dozens        of top partners ends up with hundreds of separate files (or        paper documents). This makes it impractical to answer questions        across partners.

In sum, a key limitation of using personal capability review to managepartner capabilities is that it is resource intensive. Therefore, anorganization with many partners can apply it to top partners only. Thismeans that the vast majority of the partners are still capable ofinflicting great damage on an organization by acting outside expectedconstraints (e.g., by breaking laws on hazardous materials or childlabor).

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates three disciplines to improve partner capabilities(System 100);

FIG. 2 shows the Top-Level Steps in the Partner Capability Improvement(PCI) Method;

FIG. 3 illustrates the tasks in the “Define” step of the PCI method;

FIG. 4 illustrates the tasks in the “Measure” step of the PCI method;

FIG. 5 illustrates the tasks in the “Analyze” step of the PCI method;

FIG. 6 illustrates the tasks in the “Improve” step of the PCI method;

FIG. 7 illustrates the tasks in the “Control” step of the PCI method;

FIG. 8 illustrates the sub-tasks in the “Conduct Small-Scale Test” task.The “Conduct Small-Scale Test” task is referenced in the “Improve” stepof the PCI method;

FIG. 9 illustrates the sub-tasks in the “Plan Campaign” task. The “PlanCampaign” task is referenced in the “Measure” step and in the “Improve”step of the PCI method;

FIG. 10 illustrates the sub-tasks in the “Execute Campaign” task. The“Execute Campaign” task is referenced in the “Measure” step and in the“Improve” step of the PCI method;

FIG. 11, Domain Metrics Example, provides one example of definingPartner organization metrics for several domains. This illustrates theGather organizational input task within the “MEASURE” step (FIG. 4);

FIGS. 12a and 12b , Sample Survey Fields for a Few Domains, provides anexample of a subset of survey data requirements for several domains.This illustrates an output of the “Define campaign requirements” taskwithin the “Plan Campaign” task (FIG. 9);

FIG. 13 Capability Review Guideline (example) shows a portion of oneembodiment of a document that a reviewer uses as a checklist to performa partner capability review for the Business Continuity domain. Anotherembodiment could be used for another organization for BusinessContinuity. Another embodiment would be used for a different domain

FIGS. 14a-14e provide examples of an Entity Relationship Diagram thatillustrates the content and structure of one embodiment of data storagefor a System to Manage Partners;

FIGS. 15a-15f list the business rules for the same embodiment as FIGS.14a -14 e;

FIG. 16 is an example of one embodiment of an Entity RelationshipDiagram that shows the content and structure of a Data Warehouse forreporting FIGS. 14a-14e data;

FIG. 17 compares PCI and DMAIC-Six Sigma; and

FIG. 18 summarizes the use sequence for a system for managing partners.

DESCRIPTION

In the following detailed description of the preferred embodiments,reference is made to the accompanying drawings which form a part hereof,and in which is shown by way of illustration specific embodiments inwhich the invention may be practiced. It is to be understood that otherembodiments may be utilized and structural changes may be made withoutdeparting from the scope of the present invention.

Standards enable an organization to determine the extent to which theorganization's capabilities meet generally accepted capabilityobjectives. An organization compares its capabilities against hundredsof detailed capabilities described in a standard, identifies itscapability gaps and puts in place an effort to improve its capabilitiesto meet the standard. As such, standards are a valuable resource inhelping an organization to improve its internal capabilities in manydomains.

An organization that relies on many partner organizations to carry outits mission must ensure that partners have sound capabilities in placein multiple domains. If not, the organization may be hindered orprevented from achieving its goals.

Standards could be a valuable resource for ensuring that anorganization's partners have comprehensive capabilities in place. Theproblem is that until the system described by the present invention,there was no effective way for an organization to manage all of its manydozens, hundreds or thousands of partners to achieve the hundreds ofcapabilities described by comprehensive standards in one or moredomains.

For example, say a manufacturing corporation XYZ has 4000 manufacturingsuppliers and wants to ensure that they have sound management programsin place for Environmental Impact Reduction; Health and Safety; andBusiness Continuity Management (BCM). XYZ wants to use the followingstandards to gauge its suppliers:

-   -   ISO 14001 Environment    -   ISO 18001 Health and Safety    -   British Standard 25999 for Business Continuity Management (BCM)

In addition to the requirements described by the standards, XYZ hasadditional objectives in each area for the suppliers. In this example,XYZ has approximately 100 supplier manufacturing site capabilitiesacross the three areas. There are three manufacturing sites per supplieron average. FIG. 17 illustrates the limits of 25 DMAIC-Six Sigmaapproaches to managing capability versus the use of PCI in the currentinvention.

XYZ requires a system that covers the capabilities of all suppliers. Inthe example, XYZ has 1.2 million capabilities to manage (i.e. 4000suppliers*3 sites per supplier*100 site capabilities each). In addition,any of these 30 capabilities can change at any supplier at any time,especially during and partner capability improvement project. Keeping upwith this quantity and volatility of data would be impossible without acentralized database and specialized software that suppliers can accessthemselves.

In the past, this data complexity led organizations to focus just ontheir top partners. For example, without a system according the currentinvention, XYZ selects its top 50 suppliers and rationalizes that it ismanaging about half of its manufacturing spend in dollars. There aresevere risks to this approach. Essentially, the risk boils down to thefact that the other 3950 suppliers can inflict great damage to XYZ'srevenue and brand yet XYZ is doing little to control this risk. Forexample:

-   -   The other 3950 suppliers could include some big polluters.        Therefore, XYZ would have no idea the overall environmental        impact for its supply chain is getting better or worse    -   The other 3950 suppliers could include companies with egregious        health and safety history. A newspaper article on XYZ's use of        such suppliers could adversely affect its brand    -   A disaster that impacts unprepared suppliers among the other        3950 companies could halt production of key XYZ products. After        all, XYZ cannot ship a product that is missing even a single        component. Since many components are manufactured in        economically advantaged zones, a regional disaster event could        affect many suppliers.

In the past, XYZ would have to take the significant risk of managing thetop suppliers, leaving the other 3950 unmanaged and hoping for the best.

In contrast, a system according to the present invention enables anorganization to manage an unlimited number of partners to achieveobjectives for one or more domains. XYZ could use a system according tothe present invention to measure and improve capabilities at its 4000suppliers, thereby managing more of its risks. XYZ could definecapability objectives based on generally accepted standards and couldadd other objectives important to XYZ's industry but not specificallycalled out by the standard.

FIG. 18 illustrates one embodiment in which a system according to thepresent invention manages partner capabilities without constantattention:

-   -   Measuring partner capabilities    -   Identifying partner gaps versus objectives    -   Informing partners about their:        -   gaps and gap recommendations;        -   aids in closing the gaps (e.g. references to a standard;            templates, instructions;        -   capability ratings/scores (e.g. overall risk, environmental            impact)    -   Following up with each partner    -   Tracking progress and communications until the partners reach        the organization's objectives    -   Ensuring that improvements are retained through periodic updates    -   Providing the organization with visibility across all partners        and all capabilities at all times.

FIG. 1 illustrates that Information Technology according to the presentinvention combines with the Partner Capability Improvement (PCI) method(illustrated in FIGS. 2 through 10) and domain expertise (in one or moredomains) to enable organizations with many partners to manage all ofthem effectively.

As noted above, current approaches that focus on top partners leave anorganization with a large number of partners at risk because they do notmanage the capabilities of the majority of partners.

A system according to the present invention measures the currentcapabilities of partners (for any set of capabilities and partnerschosen by the organization) and then manages improvements in partnercapabilities from the current state to the organization's objectives inone or more domains. It can be applied by large and small organizations.It can be applied to any number of partners but is particularly valuablefor organizations with a large number of partners.

In one embodiment, the organization configures objectives for a domainin the system based on its own requirements. In another, theorganization uses generally accepted standards (e.g. ISO 14001, ISO18001, BS 25999, etc.). In one embodiment, the organization bases theobjectives on a combination of standards and internally developedobjectives.

FIG. 1 illustrates a partner management System 100. System 100 usesthree disciplines to improve partner capabilities. As a result, the newapproach enables organizations to manage large numbers of partners. Thethree disciplines are the Partner Capability Improvement (PCI) Method,Domain expertise and specialized Information Technology.

First, Partner Capability Improvement (PCI) is the step-by-step methodfor managing many capabilities in one or more domains across manyexternal partner organizations.

-   -   “DEFINE”: Determine capability objectives for partners and input        into System    -   “MEASURE”: Interact with partners to gather their current        capabilities. Also correct & augment data. Unlike Six Sigma; PCI        integrates Information Technology, domain-specific input and        market research campaign techniques to scale this step to many        partners.    -   “ASSESS”: Automatically assess gaps and make recommendations    -   “IMPROVE”: Follow-up, track and offer self-help aids to close        gaps. PCI integrates Information Technology automation,        domain-specific input and market research campaign techniques to        scale this step to many partners.    -   “CONTROL”: Periodically ask partners for updates. Plan for        continuous improvement.

PCI shares the same top-level step names as DMAIC (a Six Sigmamethodology, see www.isixsigma.com). Other than that superficialresemblance, the tasks within PCI versus DMAIC are very different sincethe two methodologies have such different objectives. A quick summary ofthe differences includes the following (see FIG. 17 for additionaldifferences):

-   -   A DMAIC project focuses on decreasing variations in outcomes        from a single internal process within an organization    -   A PCI project focuses on increasing many capabilities at many        external partner organizations.    -   DMAIC uses various statistical techniques to find the few most        critical sources of internal process variation.    -   For PCI, statistical analysis is not important    -   DMAIC does not require software other than statistical        calculators.    -   PCI absolutely requires software automation to interact with        partner organizations and to manage many capabilities across the        many partners.

Second, domain experts (e.g. Environment, Social Responsibility,Business Continuity) provide input into PCI and into tailoringInformation Technology. In one embodiment, domain experts provide inputinto:

-   -   Critical metrics for the domain    -   Survey questions for the domain    -   Training materials, self-help documentation and templates to aid        partners to make improvements to accomplish the organization's        objectives for the domain

In one embodiment, system 100 combines domain expert input into theInformation Technology with domain expert support and review of a subsetof partners.

-   -   Second-level support and facilitation to help partners to        complete surveys and to understand ways to implement new        capability objectives set by the organization    -   Detailed review of the responses of some partners (e.g. top        partners or a rotating list of partners) in order to identify        qualitative gaps that may not be evident from automated        validation alone. For example, domain experts review and score a        partner's written procedures for controlling a specific risk.        Such reviews are conducted more effectively using the System        since communications and tracking are automated.

Note, as can be seen in FIG. 17, in DMAIC, a domain expert called aDMAIC Blackbelt provides domain input on the DMAIC methodology. In PCI,the domain experts are people who are experts in the domain for whichcapabilities will be improved (e.g. Environmental Impact, BusinessContinuity).

Third, a system according to the present invention requires InformationTechnology. FIG. 18 provides a high-level summary of a use sequence andsome key aspects of one embodiment of the Information Technology for theSystem to Manage Partners. Information Technology will ne discussed indetail later in this document,

One aspect of the present invention is that Domain Expert inputs intoPCI and Information Technology are isolated so that PCI and InformationTechnology 10 may be reused for many domains. While the Domain Expertinput is used to tailor the configuration to an individual domain, thefoundation of the PCI method and Information Technology remain the same.

The primary advantage of a system according to the current invention isthat for the first time an organization with many partners can managemany capabilities (in one or more domains) across all its partners, notjust its top partners. The result is significantly less risk and a morecompetitive organization.

Other important advantages include:

-   -   Domain Flexibility—Domain inputs are isolated so that the PCI        methodology and specialized Information Technology adapt to        different domains.    -   Less Effort—Makes it possible to leverage relatively fewer        domain experts, who are often in short supply, over a large        number of partners. Domain expertise is leveraged through their        inputs into the Information Technology and by supporting        partners using a combination of lower-skilled agents to work in        first-level support while saving the domain experts for tasks        like second-level support and individual partner review. In        addition, the systematic approach ensures consistency across        partners and years as opposed to a manual approach which is        necessarily person-dependent.    -   Collaboration—Takes advantage of collaboration between partners        in order to harvest collective intelligence (e.g. for        identifying risks, for benchmarking, to share best practices        anonymously) for the organization and to maximize the extent to        which partners help each other.    -   Better Data Quality—Data consistency is improved thanks to        systematic validation and a common data store. In addition, PCI        tasks for improving data quality include:    -   Data correction (e.g. wrong country chosen for city)    -   Data augmentation (e.g. importing third party data)    -   Support resources to answer partner questions.    -   Better Data Visibility—central database with common data        structure enables summing of data across partners (e.g. which        partners are lacking capability X). In addition, a central        database facilitates data export to other applications. Also, a        central database enables allows analysis and improvements that        are just not possible using separate files or paper. For        example, suppliers often share the same subcontractor or use the        same critical services provider. A disruption at such a shared        resource can disrupt many partners. PCI includes a method to        identify such situations (in the Measure step) even though        suppliers enter subcontractor names and addresses differently.        This allows the organization to reduce risks further by        considering shared resource risk in partner solutions (Improve        step).

In one embodiment, system 100 includes the Partner CapabilityImprovement (PCI) Method, the isolation of Domain Expert inputs (i.e. sothat PCI and the Information Technology are not limited to any onedomain or even a small set of domains), and Specialized InformationTechnology. System 100 integrates these three components to provide asystem and method to improve capability across all partnerorganizations.

Partner Capability Improvement (PCI) Method

PCI and DMAIC (Six Sigma) are completely different methodologies aimedat different purposes. As described in FIG. 17, DMAIC (Six Sigma)focuses on in-depth, manual statistical analysis that cause variationsin a single internal process. The manual analysis, internal focus andone process at a time approach make it ill-suited to the task ofmanaging many thousands or even millions of capabilities across partnerorganizations.

In contrast, the following aspects of the PCI method make it ideallysuited to the task of scaling an improvement regimen across an unlimitednumber of partners:

-   -   Isolating Domain Expert inputs so that PCI can be tailored to        different domains    -   Integrating Information Technology, market research and        technical support processes in order to scale PCI efficiently        across a large number of external organizations (e.g. see “Plan        Campaign” and “Execute Campaign” pages called from the “MEASURE”        and “IMPROVE” steps.    -   Integrating electronic-training techniques in order to        efficiently train large numbers of external organizations.        Examples include self-help documentation (e.g. templates,        instructions, best practices, examples), partner collaboration        technologies (e.g. wiki, forums, knowledge database search),        interactive quizzes, software automation (e.g. Business        Continuity software to help partners assess risks and create        plans for emergency management, recovery and restoration)    -   Introducing a capability review process. Since DMAIC focuses on        internal processes, review of the completeness and accuracy of        data is not usually a primary concern. External partner        organizations may have goals that conflict with the provision of        complete and accurate data. Therefore, the PCI Measure step adds        a review task to ensure that partner data and documents are        complete, current and accurate. This review task may be applied        to all partners, a subset of partners or none, according to        organization objectives and resources.    -   Integrating data improvement techniques including data        correction, data standardization, data validation and data        augmentation; data management techniques such as partner        organization merge/split/add/delete.    -   Cross-partner visibility—partner responses are stored in a        central database (e.g. transaction database and/or data        warehouse) for project management, partner scoring and progress        tracking and analytical reporting (e.g. benchmarks, dashboards,        ad hoc analysis, statistical analysis, data mining and        reporting).

Partner Capability Improvement (PCI) is the step-by-step method formanaging many capabilities in one or more domains across many externalpartner organizations.

-   -   “DEFINE”: Determine capability objectives for partners and input        into System    -   “MEASURE”: Interact with partners to gather their current        capabilities. Also correct & augment data. Unlike Six Sigma, PCI        integrates Information Technology, domain-specific input and        market research campaign techniques to scale this step to many        partners.    -   “ASSESS”: Automatically assess gaps and make recommendations    -   “IMPROVE”: Follow-up, track and offer self-help aids to close        gaps. PCI integrates Information Technology automation,        domain-specific input and market research campaign techniques to        scale this step to many partners.    -   “CONTROL”: Periodically ask partners for updates. Plan for        continuous improvement

FIGS. 2 through 9 depict the workflow of the PCI methodology. FIG. 2shows the top-level steps in the PCI methodology and includes theobjective of each step. Note that the Improve step is iterative—itrepeats until the partners achieve the capability objectives set by theorganization.

The “DEFINE” Step

FIG. 3 illustrates the “DEFINE” step which identifies specific partnercapabilities objectives based on external standards (e.g. ISO) andmanagement goals. The “Determine customer needs” task is crucial becausethe rest of the steps in PCI are oriented to achieving the objectivesidentified in this task.

In one embodiment, a single person works alone to complete the “DEFINE”step. The single person decides to perform the four subtasks in the“Determine customer needs” task. In this embodiment, few people from theorganization will be part of the project so the person skips the“Organize project” steps.

In another embodiment, the single person needs to report the status tomanagement and needs a concise description of the effort. So he or sheadds “Define scope” and “Define expectations, benefits, costs andworkplan” to “Determine customer needs”.

In another embodiment, a large effort is organized to make a significantimprovement across thousands of partner organizations (e.g. a supplychain or sales/distribution channels or organizations that assist agovernmental organization). In this embodiment, all the tasks in the“DEFINE” step are followed by a multi-person team.

The “MEASURE” Step

FIG. 4 depicts the “MEASURE” step which gathers the current capabilitiesfor the organization's partners. The most important tasks are “Gatherorganizational input”, “Collect Partner Data and Documents” and “Getfeedback within the organization”. One embodiment might include onlythese three tasks and subtasks. Note that the key metrics vary a greatdeal from one domain to another. Therefore, the “Gather organizationalinput” subtask often benefits from incorporating knowledge of thedomain. In some embodiments, a domain expert provides input into whichobjectives are most important for the organization's situation anddomain.

It should be noted that the “Collect Partner Data and Documents” taskhas subtasks that may be left in or out depending on the situation, aswill be explained further below.

In addition to the most important tasks, namely “Gather organizationalinput”, “Collect Partner Data and Documents” and “Get feedback withinthe organization”, other tasks may be important for particularsituations. For example, one embodiment, where emergency contactinformation is important, may add the “Correct telephone number and jobtitle” subtask. For another embodiment, quick emergency contact isvital, so the “Test telephone numbers” subtask is added to correct anyerrors that partners made in entering their telephone numbers. In oneembodiment, telephone numbers are tested by calling them. In some cases,the partner may need to be contacted again to get correct information(contacting the partner again is not show here to simplify the diagram).

In one embodiment, where accurate partner location information isimportant, the “Parse, correct, standardize & validate addresses”subtask is used. Addresses may be standardized manually or by testingthem against global address database services or software. In anotherembodiment, mapping partner locations is important, so the “Add thirdparty geocode data” subtask is executed.

In another embodiment, the organization may be at risk of disruptions inmaterials, services or components supplied to its partners (i.e. itpartner's supply chain). For instance, the organization may suspect thatmany partners outsource to the same subcontractor or receive materialsor components from a shared supplier's supplier or use the same keycritical service provider. A disruption at a shared resource can disruptmany partners. However such shared resources are not apparent fromsurveys since every survey is independent and confidential. Therefore,the Data Analysis Team may be assigned to the sub-task “Identify sitesshared by different partners”.

Another embodiment, for instance in the Business Continuity domain wherepartner viability important, adds the “Import third party financialdata” subtask and apply it to some or all of the partners. There aremany potential sources for financial data for both public and privatecompanies (e.g. credit card bureaus, rating agencies such as Moody's,Dun and Bradstreet). Each service has detailed documentation for whatdata they offer and how to import it. It can be as simple as importingjust an overall score for a partner or it can include other informationsuch as late payments, which can be a leading indicator of bankruptcy.In one embodiment, financial questions are added to the survey itself.The Analysis step incorporates quantitative bankruptcy models (e.g.Altman Z, Robert Altman, 1968, 2000) based on the financial questions.In another embodiment, qualitative questions (e.g. has your organizationannounced layoffs of over X % of your labor force in the past year?)combine with automated business rules in a bankruptcy prediction model.In another embodiment, a bankruptcy prediction model produces aprediction and risk rating/score by integrating quantitative andqualitative questions.

As noted above, the “Collect Partner Data and Documents” task hassubtasks that may be left in or out depending on the organization'ssituation. In one embodiment, an organization with many hundreds or manythousands of partners may need to use all the subtasks in order toefficiently reach so many partners. The “Collect Partner Data andDocuments” task provides the option to integrate mass market researchtechniques in order for the process to scale to many hundreds or manythousands of partner organizations.

In other embodiments, only a few of the subtasks are used. For example,within the “Plan Campaign” task shown in FIG. 9, one embodiment for asmaller effort may include only the following steps:

-   -   “Define partner requests (e.g. provide survey data, address        capability gaps)”. For the “MEASURE” step, survey data is a        common requirement in many embodiments    -   “Tailor application (e.g. survey questions, gaps/objectives)”        (“MEASURE” step). In some embodiments, a professional survey        designer is engaged since the formulation of survey questions        greatly influences responses. As a result, a professional survey        designed may increase survey quality. In another embodiment,        survey questions are developed by knowledgeable but not expert        people. In another embodiment, survey questions are based on a        published list of questions from an external organization such        as a standards organization.    -   “Finalize list of Partners, Partner contacts, etc.” and    -   “Determine communication events, templates and recipients”.

In one embodiment, one may add the IT Team subtasks if there will beadvanced automation and a large team. Another embodiment may include the“Define adaptive data requirements” subtask if it is believed thatpartner characteristics such as industry classification, size,operations performed, etc. have a significant affect on addressingissues defined in the “DEFINE” step.

In another embodiment, the team adds “Conduct small-scale test” before“Execute Campaign” in order to gather partner feedback from a small setof partners. This is particularly important if solution implementationcould be costly. Note: the FIG. 8 depicts the “Conduct small-scale test”workflow.

In one embodiment, the “Execute Campaign” task shown in FIG. 10 isadjusted to the organization's and partner organizations' situation. Oneembodiment for a small effort may include only the following steps:

-   -   Campaign Team: “Communicate instructions and deadline”, “Update        contact or Partner information”, “Remind periodically”    -   Partner: “Read”, “Follow instructions”, “Complete per        instructions”    -   Support Team: “Resolve question”

In one embodiment for a small effort, the “Campaign Team”, “SupportTeam” and “Data Analysis Team” may be a single person, part-time, withno separate Domain Expert or Partner Management resources.

Another embodiment may include the “Resolve with Partner” subtask whichinvolves the Partner Management/Purchasing group to contributeadditional persuasion to partners who do not initially comply with therequest to provide the required information. Non-compliant partners areescalated to the responsible manager in the PartnerManagement/Purchasing group, who then engages with the partner to ensurethat the partner provides the requested information, in some cases witha postponed deadline.

In another embodiment, there is a detailed review of the most importantpartners in order to have greater assurance that the data that theyprovided is complete and accurate. This detailed review includes the“Review Partner response in detail” and “Request clarifying informationor changes” subtasks. In another embodiment, the review takes place onone set of partners in one execution of the PCI steps and other sets ofpartners in subsequent execution of the PCI steps, in order to covermore or all partners over time. In one embodiment, a separate DomainExpert performs these subtasks. In another embodiment, a single personat the organization acts in the Campaign Team, Support Team and DomainExpert roles.

In another embodiment, where the organization seeks to achieve a highrate of compliance with a large set of partners, multiple people may beneeded on each team and all the subtasks may be needed.

The “ANALYZE” Step

FIG. 5 illustrates the “ANALYSIS” step which seeks to understand andprioritize partner gaps (i.e. the difference between the desiredcapability objective and the partner's actual capability).

In a simple embodiment, there is a clear objective (or more than one) toapply across all partners, for example, to support new regulations, lawsor organizational policy. In this embodiment, the sub-task “Automatedgap analysis and recommendations (&optional review)” maybe the onlysub-task needed.

In more common embodiments, the “Stratify capabilities by industryclass, production operation, etc.” sub-task is added because it isbelieved that the current capability may vary significantly by suchpartner characteristics. Also, the related “Calculate partnercomparisons and benchmarks per capability stratification” task is added.In another embodiment, there are multiple potential significant changesto effect in the partners so the sub-task “Prioritize gaps &opportunities” is added in order to focus resources on the mostimportant opportunities.

The “IMPROVE” Step

FIG. 6 depicts the “IMPROVE” step. It is the most important PCI stepbecause it is the step that adds real value by addressing the issues andgoals identified in the “DEFINE” step by measurably increasing partnercapabilities.

One embodiment includes only the following critical sub-tasks:

-   -   “Choose solution and set deadlines to close gaps”    -   “Plan campaign”    -   “Execute campaign”    -   The “Met objectives?” decision point which iterates the        “IMPROVE” step until objectives are met

Even though the “Plan campaign” and “Execute campaign” workflow tasksare the same in the “IMPROVE” and “MEASURE” steps, the campaign contentand effect are markedly different. In the “IMPROVE” step, the campaigncontent consists of communicating each partner's gaps versus objectivesand following up with each partner until the gaps are closed. The effectof the “IMPROVE” step is to increase partner capabilities to reach acertain measurable objective.

In one embodiment, the solution to the customer issues is obvious, sothe “Choose solution and set deadlines to close gaps” subtask may be theonly subtask needed within the “Identify improvement solution” task. Inanother embodiment, the best solution may not be obvious, so the task“List & evaluate possible solutions” is added;

In a large PCI effort, many people may have some input into thesolution. In such a case, the Improvement Team and the Domain Expert areoften primarily responsible for these steps, with review and feedbackfrom Partner Management, Campaign Team, Data Analysis Team, executivesand the IT Team. In contrast, a small effort may have one part-timeperson making the solution decision, usually with input from management.

In another embodiment, internal changes may be needed to facilitateincreased partner capabilities. For example, an objective may be toreduce the time needed to recover production at an alternate site incase the current production site for the partner is badly damaged by adisaster event. If it takes several weeks or months for the organizationto test and certify an alternate manufacturing site for a partner ofcomplex components then an accelerated process may me created at theorganization in case of disaster events.

In another embodiment, “Ask partners to implement solution” is combinedwith “Finding alternative partners” for those partners who do not meetobjectives, especially for critical components, materials and services.

As noted above, the “Plan Campaign” page and “Execute Campaign” tasksare called from the Improve step as well as the Measure step. Somesubtasks within “Plan Campaign” and “Execute Campaign” may be left in orout of the “IMPROVE” step depending on the organization's situation. Inone embodiment, an organization with many hundreds or many thousands ofpartners may need to use all the subtasks in order to efficiently reachso many partners, communicate each partner's gaps and follow up witheach partner until objectives are reached. The “Plan Campaign” and“Execute Campaign” tasks and subtasks provide the option to integratemass market research techniques in order for the process to scaleefficiently to many hundreds or many thousands of partner organizations.

In other embodiments, only a few of the subtasks are used. For example,within the “Plan Campaign” task shown in FIG. 9, one embodiment for asmaller effort may include only the following steps:

-   -   “Define Partner requests (e.g. provide survey data, address        capability gaps)”. For the “IMPROVE” step, address capability        gaps is the most common requirement    -   “Tailor application (e.g. survey questions, gaps/objectives)”.        For the “IMPROVE” step, having a vehicle for tailoring        gaps/objectives per different categories of partners is a common        embodiment    -   “Finalize list of partners, partner contacts, etc.” and    -   “Determine communication events, templates and recipients”.

In one embodiment, system 100 adds the IT Team subtasks if there will beadvanced automation. In one embodiment, system 100 includes the “Defineadaptive data requirements” subtask if the “ANALYSIS” step proved thatpartner characteristics such as industry classification, manufacturingoperations performed, etc. have a significant affect on addressingissues defined in the “DEFINE” step.

The “Execute Campaign” task shown in FIG. 10 should also be adjusted inthe Improve step per the organization's and partners' situation. Oneembodiment for a small effort may include only the following steps:

-   -   Campaign Team: “Communicate instructions and deadline”, “Remind        periodically”    -   Partner: “Read”, “Follow instructions”, “Complete per        instructions”    -   Support Team: “Resolve question”

In one embodiment for a smaller effort, the “Campaign Team”, “SupportTeam” and “Data Analysis Team” may be a single person, part-time, withno separate Domain Expert or Partner Management resources.

In one embodiment, system 100 includes the “Resolve with Partner”subtask which involves the Partner Management/Purchasing group tocontribute additional persuasion to partners who do not initially complywith the request to close gaps with the capability objective.Non-compliant partners are escalated to the responsible manager in thePartner Management/Purchasing group who then engages with the partner toensure that the increased capability objective is reached, in some caseswith a postponed deadline.

In one embodiment, system 100 implements a detailed review of the mostimportant partners in order to have greater confidence that the mostcrucial partners 10 have the capability that they state that they have.This detailed review includes the “Review Partner response in detail”and “Request clarifying information or changes” sub tasks. In onevariation of this embodiment, a separate Domain Expert performs thesesubtasks. In another variation, a single person acts as the CampaignTeam, Support Team and Domain Expert.

In another embodiment, where the organization seeks to achieve a highrate of compliance with a large set of partners, multiple people may beneeded on each team and all the sub tasks may be needed.

The “CONTROL” Step

FIG. 7 depicts the “CONTROL” step which contains the tasks thatinstitutionalize partner improvements and plan further improvements inorder to ensure that the partner organizations continue to meetobjectives on an ongoing basis.

Partner organizations should be monitored periodically to ensure thatobjectives continue to be met. In one embodiment, this is done annuallyfor all partners and quarterly for the most important partners. In oneembodiment, system 100 implements annual monitoring for all partnerswith a brief follow up semiannually or quarterly with all partners. Inone embodiment, system 100 differentiates between different types ofpartners and determines which partners are monitored during differentmonths in order to smooth the workload or take advantage of seasonalfluctuations in the organization's workload. In another embodiment,there could be an annual or semi-annual review in detail of the mostimportant partners and a high-level review of the other partners at thesame time or less frequently.

The tasks in the “CONTROL” step should be selected to match theorganization's situation. One simple embodiment of the “CONTROL” stepincludes only the following critical sub-tasks:

-   -   “Define monitoring standards and schedule”    -   “Implement monitoring plan”.

Another embodiment of the “CONTROL” step also incorporates the followingsub-tasks in order to provide greater assurance that the most importantpartners continue to meet the capability objectives:

-   -   “Define guidelines for performing a detailed review, audit        and/or test of Partners”. The purpose of this step is to        identify how to verify whether partners who say that they meet        the defined objectives actually do meet them. Many review        techniques are possible. For example:        -   Partner self-certification—one of the least expensive and            least intrusive is to require that partners to            electronically sign that their capability or compliance            meets the stated objective or to state where they fall            short.        -   Affidavit—require an affidavit that the partner meets the            objective. The affidavit can be scanned and uploaded into IT            automation that supports PCI or simply mailed or faxed        -   Procedures or report—Ask partners to upload their detailed            procedures or system report (e.g. inventory buffer stock            report) that pertains to an objective        -   Document review—Asks partners to provide comprehensive            documents that cover a domain (e.g. Business Continuity            Plan)        -   Contract—Modify contractual agreements to include the            objective        -   Audit—Visit partner sites to perform on-site audits        -   Physical proof—For example, a partner proves that key            components may be manufactured at an alternate site (i.e.            not the normal sites) by manufacturing the components at the            alternate site and then sending the parts to the            organization for testing    -   “Define criteria for which Partners should have a detailed        review, audit and/or test”. For example, in one embodiment        partner self-certification and possibly affidavits may be        required of all partners while audits and contractual changes        may be required of the top 10% of partners by revenue

Another embodiment incorporates the new partner capability objectivesinto existing partner performance monitoring. One example of thisincludes adding the objectives to an existing annual review checklist.Another example applies to organizations that calculate a performancescore or quality score for partners. In this case, the new capabilityobjective can be incorporated into that score.

Another embodiment includes a hand-off of responsibilities for thepartner capability objective to a different person or team for futureimprovements. In this case, a document to “Define ongoing owner andgovernance of standards” is helpful.

Another embodiment includes the sub-task “Evaluate project versusproject expectations” which looks for lessons learned for the benefit offuture PCI efforts.

Finally, after completing a PCI effort, the PCI methodology may berepeated for the same domain on a periodic basis. One reason for doingso is to keep up with the changing nature of requirements and regulatoryenvironment. For example, a business continuity improvement effort maybe repeated annually or semi-annually. Another reason is to put in placea regimen of continuous improvement.

In addition, multiple PCI efforts may take place at the same time in thesame organization's partners, each one aimed at a different partnerdomain. For example, one embodiment of PCI may run from January throughMarch for Country of Origin labeling laws and regulations for suppliers,another from February through April for compliance with lead-free lawsand regulations for suppliers and a third during the month of April forsupplier environmental policies. Another embodiment could cover allthree domains in one PCI project running from January through March.

Isolation of Domain Expert Input

In one embodiment, Domain Expert inputs are isolated so that PCI is nottied to a specific domain. As a result it can be applied to any partnerdomain needing improvements. The key areas of Domain Expert input areto:

-   -   Metrics (part of the Measure step)    -   Define Campaign Requirements (part of the Plan Campaign task        which is part of the Measure and Improve steps)    -   Support and Detailed Review (part of the Execute Campaign which        is part of the Measure and Improve steps)    -   Identify Improvement Solution (part of the Improve step)    -   Evaluate Project Versus Expectations (part of the Control step)

a) Metrics

Gather organizational input is the first task in the “MEASURE” step(FIG. 4). A Domain Expert works with the Improvement team to determinethe metrics that will be used to baseline partner capabilities. Eachsubtask of “Gather organizational input” is required.

FIG. 11 Domain Metrics Example is one embodiment of metrics for thedomains Business Continuity, Country of Origin, Lead-Free and SocialResponsibility. In one embodiment, PCI is applied to multiple domainswithin single, consolidated project. In another embodiment, PCI isapplied to one domain at a time, such as a lead-free initiative.Defining the Unit, Opportunity, Defect and Critical to QualitySpecification are the critical components for defining the rightmetrics.

b) Define Campaign Requirements:

In an embodiment of PCI directed at many partners, the Domain Expertparticipates in the “Define campaign goals, objectives and successcriteria” subtask that defines the strategy and tactics for the“Measure” or “Improve” campaign.

It is very common for different domains to differ greatly in the surveydata they require from partners. Therefore, it is common for some surveydata requirements to differ from one domain versus another. That is whydomain expert input is valuable in defining survey data requirements(this is one embodiment of the “Define Partner requests (e.g. providesurvey data, address capability gaps)” task).

To illustrate the survey differences and the need for domain expertinput, “FIG. 12 Sample Survey Fields for a Few Domains” summarizes thepartner 5 survey data that is requested in one embodiment of PC I. Theleftmost column lists the key forms presented to partners and the secondcolumn shows survey data fields. These two columns along with the “FieldType” column are the key inputs from the Domain Expert and ImprovementTeam to the person who finalizes the wording of the questions and thenforwards the resulting survey data requirements to IT.

Note: The rows with a “Yes” in the column labeled “All” contain fieldsthat may be relevant to all the listed domains. The fact that many dataelements apply across many domains illustrates synergies in approachingthe different domains with a common PCI approach. In addition, thetechnology and PCI method are flexible to the areas domains differencessince domain inputs have been isolated. A “Yes” in 15 one or more of thedomain columns indicates that the field is not relevant to all partnerdomains but is relevant to one or more. FIG. 12 is just one embodiment.Other embodiments could have more or fewer domains and questions. Inaddition, some organizations may run surveys for different domainseither together or independently. In another embodiment, industryorganizations and other multi-organizational associations could agree ona comprehensive standard list of questions (e.g. in order to helpassociation members to increase capabilities or to solve common issues).

The Domain Expert is expected to contribute a lot of input into partnerrequests. For example, in one embodiment the Domain Expert providesinput on which data should be requested from the partners and how thesurvey might vary for different partner types, activities, and otherstratifications of the partner organizations. In this embodiment, the“Adapt data requirements per type & importance of Partner” and “Definedetail review requirements & criteria for top Partners” tasks may beadded and the Domain Expert may provide valuable input to tailor thesurvey to the needs identified in the “DEFINE” step.

There are several media different ways that a survey may be delivered.For example:

-   -   By the internet using a Web application    -   By email    -   By telephone    -   By mail

In addition, one or more of these communication media may be used in thesame PCI embodiment. For example, in one embodiment, a request isemailed to the partner. Then an email is sent ten days later to partnerswho have taken no action. Next, a telephone follow-up is made a weeklater.

Just as Domain Expert can offer valuable input to survey requirements,they can also provide valuable input to the other subtasks of the“Define Campaign Requirements” task shown in FIG. 9.

c) Support and Detailed Review:

Support and Detailed review occur within the “Execute Plan” task, whichis in both the “MEASURE” step and the “IMPROVE” step. The Domain Expertplays a reactive, second-level support role, helping to resolve domainbusiness issues. For example, a partner may want help understanding whatneeds to be in an effective Code of Conduct (for the SocialResponsibility domain) or in a site salvage procedure (for the BusinessContinuity domain).

In one embodiment, the “Detailed Review” sub-task applies to allpartners and is conducted after the partner submits a completed survey.Its purpose is to perform a quality and completeness check of what thepartner has submitted. In another embodiment, the “Detailed Review” isperformed only for the most critical partners. In another embodiment,the “Detailed Review” is performed based on data anomalies that areassociated with inaccurate or incomplete data. This concept is similarto how the IRS decides which businesses and persons to audit. Forexample, rather than auditing all businesses or just the largestbusinesses, the IRS looks for data exceptions such as deduction amountsthat are unusually large compared to income.

FIG. 13 Detailed Review Guideline Example includes the first page ofguidelines for a Detailed Review by the Domain Expert, in this case forpartner's Business Continuity Plan. In one embodiment, the guidelinesare three pages long, in another just one page is needed while a thirdembodiment requires tens or hundreds of pages of guidelines, templatesand instructions. In one embodiment, the Domain Expert is the mainauthor of the guidelines. In another, the project manager or a technicalwriter writes them.

d) Identify Improvement Solution

“Identify Improvement Solution” is the first task in the “IMPROVE” step.In one embodiment, a Domain Expert works with the Improvement team tolist and evaluate potential ways to improve Partner capabilities toreach objectives based on past experience and research. In anotherembodiment, the Domain Expert is involved in choosing which of thepotential solutions to actually implement.

e) Evaluate Project versus Expectations

“Evaluate project versus expectations” is a subtask in the “CONTROL”step. In one embodiment, a Domain Expert provides useful input to therest of the team in identifying lessons learned from the PCI project inorder to improve the effectiveness of the next PCI project.

f) Information Technology for a System to Manage Partners

A system according to the present invention requires InformationTechnology in order to manage the large number of capability objectivesrequired by each domain across many partners. FIG. 18 is a high-levelsummary of a use sequence and shows some key aspects of one embodimentof Information Technology for a System to Manage Partners.

The use sequence shown is:

-   -   DEFINE: The organization defines partner capability objectives        in the system    -   MEASURE: The system gathers partner capability facts    -   ANALYZE: The system identifies gaps, i.e. partner capability        facts that differ from objectives    -   IMPROVE: The system communicates gaps and associated        recommendations and aids to partners    -   IMPROVE: The system tracks communications and partner progress        until partners reach objectives    -   CONTROL: The system continues tracking and periodically requests        updates from partners

Definitions of terms used in FIG. 18 follow:

-   -   Partner Capability Fact:        -   Actual data about partner capabilities        -   e.g., actual responses to questions, existence/non-existence            of supporting evidence for partner claims, reviewer            approval/disapproval of partner claims, etc.    -   Objective:        -   List of acceptable Facts for a capability        -   e.g., desired responses to questions sometimes requiring            sufficient supporting evidence and sometimes further            requiring a review and approval by the organization    -   Gap: Fact not matching objectives        -   Facts not on the list of acceptable Facts for a capability        -   e.g., It is desired that partners have tested a certain            procedure within the past 12 months. If the partner last            tested the procedure 25 months ago, that is a gap    -   Recommendation:        -   Description associated with Gap which illustrates the            organization's change request for the partner's capability        -   e.g., “ISO 22399 requires companies to have a written crisis            management procedure at least every year. Please test your            written crisis management procedure and upload evidence that            you did so into the system. For further information, see . .            . ”    -   Communicate & Track:        -   Regimen to communicate and follow-up with partners to            improve the capabilities highlighted by the identified gaps        -   e.g., Initial email & follow-ups with link to gaps &            recommendations report        -   e.g., System records key events in a History table. Key            events could include gap creation, gap closures,            communications to and. from partners, etc.

FIG. 18 shows some key aspects of one embodiment of InformationTechnology for a System to Manage Partners. Another key aspect not shownis automated reporting. Automated reporting provides visibility into thecapabilities for each partner as well as across all partners. Forexample, without automated reporting it would not be practical toquickly get a list of all partners with a gap on a given capability orto keep up with continuous updates in partner capabilities as partnersmake progress in closing gaps.

Other potential aspects of another embodiment of Information Technologyfor a System to Manage Partners include:

-   -   Data Correction & Augmentation—facilitates correction of partner        data entry errors as well as augmentation of partner data from        third party sources    -   Capability Review—enables organization's personnel to review        evidence for partner capabilities, create additional gaps or        close gaps and to track such events in the central database.    -   Scoring—rates and scores partners for their capabilities    -   Gap Prioritization—in the “Analysis” step, gaps may be        prioritized. Some gaps may be de-emphasized or closed across        many partners.    -   Help Resources—a set of templates, instructions and other tools        to aid the partner in improving capabilities    -   Support Request Tracking—tracks partner questions and the        organization's responses    -   Integration with Domain-Specific Modules—communication of data        with other modules at the organization. Some embodiments could        integrate user interface as well.

Information Technology (IT) Embodiment Examples

This section describes in detail various embodiments of a System forManaging Partners, included some advanced embodiments of the System. Inthe following detailed description of the preferred embodiments,reference is made to 5 the accompanying drawings which form a parthereof, and in which is shown by way of illustration specificembodiments in which the invention may be practiced. It is to beunderstood that other embodiments may be utilized and structural changesmay be made without departing from the scope of the present invention.

It is possible for IT to provide automation for many of the PCI tasks.Some embodiments have more automation than others. Many of theembodiments described below illustrate advanced embodiments in order toshow the potential for IT automation to realize greater efficiencies andeffectiveness with more partners compared to what a more basicembodiment could illustrate. For example, one embodiment of ITautomation includes the following software modules:

1) Flexible Standards-Based Measurement Tool (FSMT)

-   -   Key aspect: Gathers partner facts

2) Gap Initiation, Review & Tracking (GIRT)

-   -   Key aspect: Identifies and tracks gaps

3) System for Continuous Operational Risk Evaluation (SCORE)

-   -   Key aspect: Rates & scores partner capabilities for domains

4) Security Administration, Data Management & Transfer (ADM)

-   -   Key aspect: Management of data access

5) Global Latitude-Longitude, Address Standardization & Shared Sites ID(GLASS)

-   -   Key aspect: Corrects and augments partner data

6) Communications Engine (COM)

-   -   Key aspect: Automates communications to partners

7) Collaborative Help Resources (Help)

-   -   Key aspect: templates, instructions and tools for partners

8) Reporting Portal (Portal)

-   -   Key aspect: visibility of capabilities across all partners

9) Support Request Tracking (Support)

-   -   Key aspect: tracks partner questions and the organization's        responses

10) Business Continuity Management (BCM) or other domain-specific module

-   -   Key aspect: integration of the modules above with another        specialized module(s) at the organization

One embodiment could have all these modules. FIG. 16 shows a databaseschema for an embodiment of a database for a reporting portal. As can beseen in FIG. 16, a data center 150 (such as a server or collection ofservers) is connected to a network 152 via network interface device 154(such as a router, hub or switch). The database and its associatedsoftware according to one embodiment of the present invention is storedand executed on server 150.

FIGS. 14a-e and 15a-f show an embodiment of a database schema for all ofthe other modules. In one embodiment, system 100 implements all modulesin one database schema while another could use multiple database. In oneembodiment, system 100 implements a subset of these modules. A differentembodiment could include some or all of the key underlying features butorganized into different software modules. Another embodiment couldorganize the modules into one big module. Different embodiments couldhave all of the modules but with a subset of features or with additionalfeatures.

In one embodiment, the IT automation, data storage, IT reporting andanalysis, and other aspects of IT are implemented by the organizationwithin its data centers 150. In the other, they are implemented by apartner that provides software and services for managing partners for anumber of client organizations.

A description of business rules and features of various embodiments ofeach module follows:

1) Flexible Objectives-Based Measurement Tool (FOMT)

In one embodiment, FSMT is a Web-based, adaptive application where eachsurvey measurement (e.g. partner response or other facts) can bevalidated and related to specified objectives for a domain. FSMT isconfigured in the DEFINE step of PCI and then mainly used in the MEASUREand IMPROVE steps.

FSMT adapts the survey questions, validation and objectives per the typeof partner and partner activity being surveyed. In addition, oneembodiment enables the organization to require supporting evidence forany set of questions in the survey. In one embodiment, the moduleincludes a way for partners and evidence reviewers to interact and tracktheir interactions/communications during the review of the informationand document evidence submitted by the partner. Key aspects of thismodule include:

-   -   Flexible, Adaptive Surveys for Any Domain    -   Partner Capability Review and Approval    -   Offline Data Entry Option

Flexible, Adaptive Surveys for Any Domain:

This module adapts data gathering to any set of domains, objectives andpartner types, partner activities, etc.

In one embodiment, questions, responses, objectives (i.e. the set ofresponses to a question that meet the organization's objectives):

-   -   Have configurable format, configurable validation, configurable        navigation, configurable hierarchy and configurable grouping.        The survey User Interface and reporting is created automatically        from the configuration data:        -   Configurable format: e.g. question subheadings, text,            question number, question order, question help text,            reference to an external standard or organizational            document, and question short description for error messages.        -   Configurable validation: e.g. validation type (e.g. drop            down box list, date, integer, etc.), required/optional for            different partner types and/or activities, question            workflow, acceptable set of responses        -   Adaptive navigation: e.g. Users have a way to navigate            between multiple surveys; Contacts representing multiple            partners (e. g. manufacturers representatives) navigate            between their assigned partners; Partners contacts see the            data only for their assigned partner(s);        -   Configurable hierarchy: e.g. Questions can be related to the            partner as a whole or units within the partner (e.g. sites,            contacts, divisions, parts, etc.)        -   Configurable grouping: e.g. Within a hierarchy,            questions/responses/gaps may be presented in the User            Interface and reports within summary categories    -   May require supporting evidence for some or all questions:        -   In one embodiment, the partner must upload a document            showing supporting evidence if the partner response is in            the list of acceptable responses for a question.        -   In one embodiment, the partner uploads a document, links the            document to the question that it provides evidence for. Such            documents are then reviewed by the Domain Expert who can            accept the evidence or mark it as insufficient. The User            Interface makes clear to the reviewer and partner which            questions have insufficient or missing evidence        -   In another embodiment, the evidence is provided verbally (or            by fax or email) to someone at the organization who marks            the evidence for the question as acceptable or not.    -   May be related to one or more domains    -   May share some of the same configuration: e.g. some questions        share the same answer list of values (e.g. Yes, No)    -   Questions/response/objective are related to an underlying        partner data model (e.g. some questions related to partner as a        whole, others to partner contacts, others to partner sites,        others to partner parts, others to partner site/part/contact        activities, others to just certain partner activities or partner        types, etc., or to a subset thereof    -   Are presented to the partner only if the partner has        configuration data that matches the question conditions (e.g.        the right domain, partner type, activity)    -   Allows more than one type of survey for each partner (e.g. for        different domains or within the same domain)    -   Automatic report generation based on question configuration        (i.e. adding a question adds reports/charts related to the        question)    -   Are recurring. In other words, the organization asks similar        questions each year and responses from the prior survey are        saved as a starting point for the supplier for the next year. In        another embodiment, the organization has additional one-time        surveys for specific capabilities that are time-sensitive and        not repeated/recurring.

Offline Data Entry Option:

In some situations, a partner contact person may not be able toimmediately answer survey questions without research or forwardingquestions to colleagues. In one embodiment, a supplier has to get suchinformation for a long list of parts provided by the organization's webapplication. The web application allows the supplier to download aspreadsheet containing the supplier's parts and other related data in acertain format. The offline spreadsheet option allows the supplier toget input from supplier colleagues without having to train colleagues onhow to use the web application. The offline spreadsheet allows thesupplier to gather data from various colleagues by forwarding thespreadsheet by email. Once the supplier completes the spreadsheet, he orshe can return to the web application, sign in and click an “Upload”button to browse to the spreadsheet and upload it. When the file isuploaded, the application performs a long list of validations. The firstset of validations confirms that the column labels have not changed inany column as this may indicate a format chance (e.g. the suppliersadded or deleted a column). After that, the application confirms thatthe values in each cell are valid. For example, it checks that the part# is one of the parts assigned to the supplier.

The application creates error messages if needed and associates themwith the problematic line(s). The end user can correct the situationonline or by downloading the errors to a spreadsheet to correct themthere and then re-upload. An error message in the spreadsheet indicateswhich validation failed.

In another embodiment, a similar offline data process is followed for adifferent subset of survey data or even all the other survey data. Inanother embodiment, a similar offline data process is used for otherpartners (besides suppliers).

2) Gap Initiation, Review & Tracking (GIRT)

In one embodiment, a GIRT module identifies differences from objectives.GIRT is configured in the DEFINE step of PCI and then mainly used in theANALYZE and IMPROVE steps.

Gap Initiation:

In one embodiment, gaps are generated as follows:

1. Automatically.

-   -   Gap business rules compare response to questions versus the        response goals in order to generate a gap. For example, a        multiple choice question may have multiple acceptable responses        and other responses that generate a gap.    -   Questions can be configured to require evidence. Lack of        evidence creates a gap. In one embodiment, certain question are        configured to require that if the partner response to a question        is among the list of acceptable responses, the partner must        upload a document as supporting evidence. Lack of such a        document creates a gap.

2. By a system user in the organization. A person in the organizationcan create or close a gap.

-   -   In one embodiment, a person performing a capability review may        create a gap if the documentation shows that the capability is        lacking or that there is insufficient evidence that the partner        has the capability    -   In another embodiment, a person in the organization may close a        gap. For example, the person may close the gap if after        communicating with the partner it is clear that the partner has        the capability in place but could not receive permission from        management to provide documentation

Gap Closure:

In one embodiment, gaps are closed as follows:

1. Automatically due to change in organization

-   -   In one embodiment, an organization may decide to close certain        types of gaps for a subset or all partners that have them. For        example, an organization may lower the priority of an        objective/gap after reviewing the measurements of its partners,        sometimes in order to help partners concentrate on the most        important gaps. Another example is that gaps of a certain type        may be closed after a certain date due to relative        insignificance or due to giving up on attaining the objective

2. By a system user in the organization.

-   -   A person in the organization can close a gap for particular        partners.

3. By an action of a partner in the system, combined with a businessrule.

-   -   For example, a partner may address a gap by making internal        improvements and providing supporting evidence of the        improvement

Gap History:

In one embodiment, GIRT creates gap data objects, stores a historyinteractions between the reviewer and surveyed partner organization aswell as a history of changes in gap status. In another embodiment, theobjectives are hardcoded into a report which calculates gaps when itexecutes by comparing the partner responses to the hard-coded objectivesin the report definition.

Partner Capability Review, Tracking and Approval:

In one embodiment, the organization selects a subset of (or all)partners to undergo a capability review by the organization's domainexpert or other personnel. In one embodiment, the organization markscertain partners manually as requiring a capability review. In anotherembodiment, partners are selected based on automated business rules(e.g. suppliers who supply more than a given dollar amount of parts,materials or services or “premium” partners).

In one embodiment, when such a partner completes the survey, the DomainExpert (or other personnel from the organization) is notified to beginthe capability review as soon as a selected partner submits a completeset of data and documents. In one embodiment, the system enablesorganizational personnel to pick selected partners that are ready for acapability review from a queue.

In one embodiment, the system enables appropriate organization personnelto

-   -   Review the partners data and documents in the system,    -   Record additional gaps in the system beyond those that were        detected automatically by the system (e.g. supplier has a        procedure but it is inadequate)    -   Have the option to provide comments to the partner. An automated        history log stores comments to and from the partner, gap status        events, etc.    -   In one embodiment, the system communicates gaps, recommendations        and help materials to the partner as well as follows-up with the        partner until the gaps are closed. In one embodiment, gaps on        some questions or groups of questions are not communicated. For        example, in one embodiment, prediction that the partner will go        bankrupt are used by the organization but are not communicated        to the partner.

In one embodiment, if the partner's information and documents meet theorganization's standards, then the reviewer approves the partner.

In another embodiment, partners that do not close their gaps (or aprioritized subset of gaps) by a given date are flagged for additionalmotivation by the organization (e.g. purchasing can reiteraterequirements to close gaps in order to stay a supplier).

3) System for Continuous Operational Risk Evaluation (SCORE)

In one embodiment, SCORE calculates summary statistics (e.g. a numericalscore and rating) for a partner in one or more domains by comparingobjectives to gaps and considering the importance of the gaps (e.g.points, “must haves”; etc.). The numerical score and rating provides tothe organization a quick summary of the partner's capability in one ormore domains. In one embodiment, the scores are calculated based onbusiness rules, configuration data (e.g. points to deduct for incorrectanswers) and database data (e.g. from FSMT, GIRT, domain-specificapplications and third party data). SCORE is configured in the DEFINEstep of PCI and then mainly used in the ANALYZE and IMPROVE steps.

In one embodiment, the SCORE module calculates and overall rating (e.g.Green, Yellow, and Red) and numerical score for the partner and for thepartners' sites. In another embodiment, a rating and score is calculatedfor the partner and its contacts. In another embodiment, a rating andscore is calculated for the partner and its critical components ormaterials.

In one embodiment, scores are calculated by adding the points awardedfor each question. An arbitrary cutoff is defined for each rating (e.g.Gold=80+ points, Silver=50-79 points, Bronze=35-49 points; Tin=0-34points). In one embodiment, some questions have more points than others.In another embodiment, questions are of equal value.

In another embodiment, ratings are based on meaning. For example, “Red”means Lacking Fundamentals, “Yell ow” means Partial (or uncertain) and“Green” means Sound Fundamentals. Unacceptable responses to “must have”questions result in a “Red” rating. Unacceptable responses to “nice tohave” questions does not negatively affect the rating. Otherunacceptable responses are sufficient to put the partner (or partner'ssite, or partner's contact) in the “Yellow” category.

In another embodiment of reporting based on the Altman Z bankruptcymodel, the ratings are “Red” for Bankruptcy Predicted, “Yell ow” forUncertain and “Green” for Safe.

In one embodiment, a maximum and minimum score is assigned to each colorrating. The importance of any unacceptable responses results in arating, while the points assigned to questions result in deductions fromthe maximum score for the rating. In another embodiment, acceptableresponse result in additions to the minimum score for the rating.

In another embodiment, raw scores are normalized using a business rule(e.g. on a pro-rata basis) to a convenient scale such as 0-100. Forexample, if the maximum raw number of points is 212, achieving thatnumber would result in a final score of 100.

In another embodiment, certain personnel from the organization canoverride ratings, points and scores.

In one embodiment, scores are recalculated for any changes that thereviewer or partner submits.

4. Security Administration, Data Management & Transfer (ADM)

In one embodiment, ADM keeps data secure and enables securetransformation/transfer of data per partner and client organization'srequirements. ADM is configured in the DEFINE step of PCI and thenmainly used in the MEASURE, ANALYZE and IMPROVE steps.

Data and Security Administration:

In one embodiment, a person in the organization is given an“Administrator” role in order to be able to correct partner set up data,provide support and to approve an account for a new contactperson/system user at a partner. In one embodiment, 20 the Administratorcan see and edit any partner and can even edit information that thepartner cannot, such as the partner type and partner name. In oneembodiment, the application sends an email to the Administrator when anew account request is made. The request includes the person's contactinformation and partner organization name. In one embodiment, thepartner enters their organization name in a text box (a drop down box isnot used because no partner should be able to see the name of the otherpartners). The Administrator's form displays the partner organizationname that the partner contact entered as well as a drop down box for theAdministrator to match the organization name that was entered to thelist that is in the database.

In order to cut down on requests for new accounts, one embodimentincludes a “Forget your password?” link. Clicking on the link opens aform with an email address field. The partner types in their emailaddress. If the email address is invalid, the application displays anerror message. Otherwise, the application emails the new password to thepartner.

In another embodiment, this functionality is not needed because all useraccounts are handled by another system with which this system isintegrated (i.e. “single sign on” feature).

Secure Data Transfer:

In one embodiment, ADM supports IT industry standards for securetransfer of data (e.g. XML, web service, EDI, SFTP, HTTPS, etc.) fromthe organization to partners so that partners can use the data that theyentered for other customers as well. This provides added value to thepartners and results in greater partner participation. In oneembodiment, ADM enables partners to adjust the format of the data thatthey entered and to determine which data will be public and which staysprivate for other customers. In another embodiment, the organizationoutsources the IT and the secure data transfer is needed to get the datato the organization once the outsourced partner gathers the data onbehalf of the organization.

5. Global Latitude-Longitude, Address Standardization & Shared Sites ID(GLASS)

In one embodiment, GLASS parses, corrects, standardizes and augmentsdata entered by partners. GLASS is mainly used in the MEASURE step.

Data Parsing, Correction and Standardization:

In one embodiment, Data Analysts have screens that allow them to correctdata. Rather than viewing partners one by one, they can view the contactdata for all partners in one form. This allows them for look formistakes in the formatting of telephone numbers that cannot be validatedby the form. One embodiment of the application has a spell check whichhelps the Data Analyst to find and correct spelling mistakes in thecontact's Job Title field. The Data Analyst can also sort by any column.For instance, sorting by Country shows a site in the city of Seoul inNorth Korea, so the Data Analyst corrects the country to South Korea. Inanother embodiment, data correction work is performed via spreadsheetsand then the updated spreadsheet data is imported into the database. Inanother embodiment, spreadsheets are used as the data store.

Addresses are exported into an address validation application whichstandardizes the address format and corrects the entered address ifneeded. Valid address matches also are assigned a latitude andlongitude, using third party software and service resources. Otheraddresses need to be handled manually by the Data Analyst.

Data Augmentation:

In one embodiment, data augmentation includes adding latitude &longitude to site addresses so that they can be mapped. In anotherembodiment, data augmentation includes adding partner financial datafrom a third party source. Still another embodiment augments partnerdata by identifying when the same subcontractor sites and criticalservices are used by different partners.

In one embodiment, the process for data augmentation is as follows: TheData Analyst sorts by country and city to try to find sites shared bymore than one partner as well as critical service providers shared bymultiple partners. For instance, several suppliers may outsourceassembly to the same site in Taiwan. After identifying sites andservices that are essential to many partners, the organization can workwith the partners to mitigate the risk of many partners being stopped bythe outage of a single outsourced site or service.

In one embodiment, data parsing, correction, standardization andaugmentation work is performed in a database-driven application. Inanother embodiment, the work is performed using spreadsheets and thenthe updated spreadsheet data is imported into the database. In anotherembodiment, spreadsheets are used to both do the work as well as tostore the data.

In one embodiment, the organization manages data changes such as partnerorganization merges, splits, adds and deletes as well as partner contactadds and deletes. In another embodiment, this work is outsourced to apartner service provider to perform on behalf of the organization.

In another embodiment, the Data Improvement step is skipped because ofresource constraints in the organization.

In still another embodiment, financial information from third partysources is imported into the database (or spreadsheets) in order to beable to identify partners with financial issues early in order to limitproduct and service delivery risk from bankrupt partners or financiallystrapped partners.

6) Communications Engine (COM)

In one embodiment, COM sends notifications (e.g. email, letters,telephone calls) and processes emails and telephone calls received basedon flexible workflow configuration and data in any data store (e.g.database, file storage, secure web service request, etc.).

In one embodiment, notifications can be sent in batch or ad hoc:

-   -   Batch: Can initiate running the application automatically        according to a configurable frequency (e.g. by scheduled task)    -   Ad Hoc: Arty appropriate module can call it as needed in real        time to send it information needed to communicate to appropriate        persons at partners or the organization

In one embodiment, all communications are registered in a log so thatlater the organization can query on communications. In anotherembodiment, communications may be stored in advance of sending, to allowtime to review, update or reschedule individual communications. Inanother embodiment, certain suppliers may be excluded fromcommunications (e.g. due to a business rule such as don't sendnon-urgent communications if another communication was sent in the pastfew days; or don't send emails to a certain partner until a certaindate).

COM is configured in the DEFINE step of PCI and then mainly used in theMEASURE and IMPROVE steps.

Various tools may be used to create a communications module. In oneembodiment, email notification reminders are sent using a combination ofMicrosoft Access and Microsoft Outlook. In another embodiment, a personsends email notification reminders by copying and pasting a list ofpartner contacts from a database query into the BCC field of an emailmessage.

In yet another embodiment, an enterprise, server-based application (e.g.Microsoft SQL Server 2005 Notification Services, Microsoft SharePoint,.NET, Java or another software package or a service provider thatprovides services hosted on the internet) sends emails or othercommunications media. Each communication is set up in advance based onfour main inputs:

-   -   Event: The event specifies when the notification should be sent.        In one embodiment, a notification is sent when to thank the        partner when the survey is completed. In addition, time-based        notification reminders are sent if the partner did not complete        the survey after a certain amount of time since the survey        period started.    -   Template: The template is the format of the email with some        variables. For example, it allows the recipient's first name to        be printed after “Dear . . . ”, the partner's name and the        contact login and password to be in the message    -   Data Source: This is the data that is applied to the template in        order to create the email notification. In one embodiment, the        data source may be a database query, function or stored        procedure. In another embodiment, the data source may be a file.    -   Who to send it to. In one embodiment, this is specified by        partner contact role (e.g. email to the partner BCP contact and        cc the partner account manager). In another embodiment, it is        specified by including a SQL script    -   Media: In one embodiment, the communication is sent by email or        SMS. In anther embodiment, the communication is sent by letter,        followed up on by automated telephone calls if there is no        response to the letter.

7. Collaborative Help Resources (Help)

In one embodiment, Collaborative Help Resources aid partners inunderstanding how to close their gaps and makes it easier for them to doso. Collaborative Help Resources are configured in the DEFINE step ofPCI and then mainly used in the IMPROVE step.

Different embodiments of Collaborative Help Resources include any one,more than one or all of the following:

-   -   Collaboration    -   Training    -   Self-Help    -   Workflow    -   Document Management

Collaboration:

In one embodiment, the organization sets up a collaboration websitefacilitates knowledge sharing between different partners and betweenpartners and the organization. In one embodiment, the collaborationwebsite enables the partners to share information, provide mutualsupport and to give feedback to the organization through forums, blogs,social networking and wikis. In another embodiment, collaborativedocument management enables partners and the organization to securelyreview and make edits to the same document even though they are indifferent locations. In another embodiment, the organization uses thecollaboration website for quick, ad hoc surveys of some or all of theirpartners. In another embodiment, a blog allows Domain Experts and othersin the organization to communicate without sending emails. In anotherembodiment, communication between partners and with the organization isenhanced by group calendars, social networking software, blogs, wikisand ad hoc surveys and participants also make use of automated emailnotifications, RSS, SMS, instant messaging, VoIP, real-time presence,task coordination and issue tracking.

In another embodiment, partners pose questions and answers to each otherin a forum. For instance, they are able to discuss how others areplanning to address the risk of a possible Flu Pandemic or to exchangeinformation on useful third parties to help to address gaps (e.g.consultants, associations, software, and service providers).

The organization also taps the collective intelligence of hundreds orthousands of partners to identify opportunities, risks and solutions toissues. For example, previously, risk data was mainly available frominsurance companies. Yet in one embodiment, hundreds or thousands ofpartners acting together provide collective intelligence to theorganization about which risks are most common in different parts of theworld or and which subcontractors and critical service providers areused by the most partners.

Training:

In some embodiments, automated training techniques enable theorganization to efficiently train large numbers of externalorganizations. In one embodiment, a website makes self-helpdocumentation (e.g. templates, instructions, best practices, videos,examples) available to partners. In another embodiment, the survey canincorporate interactive quizzes/answers as well as self-helpdocumentations. In another embodiment, software automation is madeavailable to partners to directly increase their capabilities. Forexample, risk processes can be strengthened through risk assessmentsoftware as well as software to create plans for emergency management,recovery and restoration.

Self-Help:

In another embodiment, a self-help website is set up with templates,samples, instructions, training videos and software to help partners toaddress gaps. The self-help materials cover all aspects of implementingsound domain capabilities at the partner. For example, in oneembodiment, the self-help website is for the Business Continuity domain,and covers all important areas of Business Continuity, such as BCMPolicy, Site Risk Assessment & Impact Analysis, Prevention andMitigation, Emergency Response, Crisis Management, Recovery,Restoration, Training, Testing & Ongoing Governance. In anotherembodiment, the self-help website is combined with the othercollaboration and training approaches described above.

Workflow:

In one embodiment, a survey status field and data completion states areused for reporting partner status. The status field starts with“Incomplete”. In one embodiment, the partner emails the support team orDomain Expert to ask for clarifications, more documents, etc. In oneembodiment, the survey status changes automatically to “Complete” whenthe partner provides all required information and clicks a survey buttonto indicate that the survey is complete.

In one embodiment, a notification system follows-up with partnersautomatically until they meet objectives. In another embodiment, anypartner not meeting the objectives (or a subset thereof) by a deadlineare escalated to partner managers who apply additional persuasion orfind other partners.

In one embodiment, completed survey information is then reviewed by aDomain Expert. When asking for clarifications, the Domain Expert changesthe status to “Clarify”. After the partner satisfies the organization'srequest, the Domain Expert changes the status to “Approved”. Theapplication records the update person, date and time for every update.

In another embodiment, there is no status field but there are dateattributes for the “Complete” date, the “Clarify” date and the“Approved” date.

In one embodiment, the Domain Expert is assigned an application rolethat enables him or her to see the information from all the partners. Onthe other hand, an individual partner can only see the one partner'ssurvey information so that each partner's information is keptconfidential.

In another embodiment, there is no detailed review and the partner isconsidered complete when the partner provides all required informationand indicates that the survey is completed. In this case, there is noneed for the Domain Expert to be able to see the information from allthe partners.

Document Management:

In one embodiment, the organization wants to review partner plans,procedures or policies for some of the Domain surveys to certain typesof partners. In this embodiment, partners use a web application toupload documents into a database. In one embodiment, a web applicationpresents a template document for the partner to download, fill out andthen upload. In other embodiments, partners do not need to use thetemplate document and can upload a document in any format. Whenuploading a document, the partner chooses which sites it applies to.Every document uploaded by partners is archived. Deleting a file bringsback the previous file from archive. In other embodiments, softwareprovides forms that adapt the questions, help text, etc. to the type ofpartner and store the responses in a database. Another embodiment maycombine document templates, partner documents and adaptive software.

In another embodiment, the organization wants to review partnerdocuments but does not have a document management system. Therefore theorganization emails the document template and receives completeddocuments by email and stores them on a PC or shared network drive.

8) Reporting Portal (Portal)

In one embodiment, a Reporting Portal provides visibility at all timesinto partner-specific information as well as cross-partner summaries andcomparisons. The Reporting Portal is configured in the DEFINE step ofPCI and used in all the other steps.

Report Creation:

Software module that that enables the organization to produce reports onthe data collected from partners. In one embodiment this is a web-basedportal with standard and ad hoc reports, charts, dashboards, analysis,benchmarks and campaign management. In another embodiment, it is asimple module using office productivity application such as MicrosoftAccess and/or Microsoft Excel.

In one embodiment, a single Portal is used to report the data frommultiple domains. In one embodiment, a web page includes dashboardcharts showing key metrics from multiple domains. In another embodiment,the Portal includes not only reporting but also collaborationtechnologies for the organization's team (Note: this collaboration isseparate from the collaboration between partners). Examples ofcollaboration tools include group calendar, social networking software,blogs, wikis, automated email notifications, RSS, SMS, instantmessaging, VoIP, real-time presence, task coordination, documentmanagement and issue tracking. In another embodiment, the Portal is adocument management system that allows team members to post reports thatthey produce without a formal reporting software program.

In another embodiment, the Portal is customized for a single domain,Business Continuity Management. The home page includes collaborationfeatures discussed above plus a Business Continuity Summary chart thatshows the number of partners with Green/Yellow/Red overall BusinessContinuity rating. In one embodiment, clicking the chart opens up thedifferent categories of Business Continuity of which the overall ratingis composed. In one embodiment, the overall Business Continuity ratingis composed of separate ratings for the categories Bankruptcy Risk,Disaster Risk and Day-to-Day Interruption risk. In one embodiment,clicking the Business Continuity Summary chart opens up a separate chartfor Bankruptcy Risk, Disaster Risk and Day-to-Day Interruption risk. Inone embodiment, each separate chart shows the number of suppliers with aRed/Yellow/Green/Unknown rating for that category. In one embodiment,clicking on a category opens charts showing the ratings forsubcategories. In one embodiment, clicking on the subcategory chartopens a report showing summary data for each supplier for thatsubcategory.

In one embodiment, the Bankruptcy Risk category is composed of thefollowing subcategories:

-   -   Altman Z Financial Risk Score (Altman, N Y U, 1968, revised        2000),    -   Qualitative Financial Risk score (based on qualitative questions        like “Has you company announced layoffs of more than 20% of the        workforce in the past year?”) and    -   Third Party Risk (based on data imported from Third Party Risk        rating organizations such as Dun & Bradstreet, Moody's, S&P or        Fitch, etc.).

Another embodiment could categorize Bankruptcy Risk differently or focuson a subset of Bankruptcy Risk.

In one embodiment, the Disaster Risk chart is composed of the followingsubcategories:

-   -   BCM Policy & Management Review    -   Site Hazards & Prevention    -   Critical Material, Product and Service Providers    -   Site Emergency Response    -   Site Crisis Management, Recovery & Restoration    -   Site Testing & Ongoing Governance

Another embodiment may categorize Disaster Risk differently or focus ona subset of Disaster Risk.

In one embodiment, the Day-to-Day Interruption Risk is composed of thefollowing subcategories: Facilities & Security; Fire & Flood Protection;IT & Telecommunications; Labor; Power; Transportation.

Another embodiment could categorize Day to Day Interruption Riskdifferently or focus on a subset of Interruption Risk.

In another embodiment, the Business Continuity Summary chart is made upof completely different categories. There are categories for BusinessContinuity document (e.g. whether the partner provided one, reviewstatus, review rating), the recovery time objective metrics andalternate site capability. In one embodiment, categories and the treestructure are configurable. In another embodiment, drilling down on achart yields a different result (e.g. opening up a report or adocument).

In one embodiment, each question is assigned to a subcategory, whichthen rolls up to a category which roles up to the overall businesscontinuity domain, which then rolls into dashboards showing key metricsfor multiple domains. In another embodiment, questions can be assignedto multiple subcategories. In another embodiment, additional levels areadded to the hierarchy. In another embodiment, some levels are removed.In another embodiment, the levels are named differently.

In another embodiment, the Reporting Portal includes a number ofstandard reports on the data, such as supplier status summaries, sitesummaries, critical parts summaries and contact summaries. In anotherembodiment, the Reporting Portal enables team members and others fromthe organization to create new “ad hoc” reports. In another embodiment,the Reporting Portal includes the collaboration tools, the dashboardcharts, standard reports and ad hoc repots.

In one embodiment, some reports and charts are generated automaticallybased on survey question configuration data. There is a stored procedurethat is passed the question identifier based on user events (e.g.clicking on a report title). The stored procedure then reads thequestion configuration data to produce report formatting such as thetitle, question and answers. Before executing the report, the reportingapplication prompts for user-enterable report parameters such as partnertype or name if applicable. In one embodiment, a report and chartdisplay the percentage of partner organizations with each of the answersto the question (E.G. 42% answered Yes, 45% No and 3% Unsure). Inanother embodiment, a report and chart show all the questions andresponses by a particular partner. In another embodiment, a report listsall the partners with a particular response to a particular question(e.g. List of Partners with no Sprinklers). In one embodiment, the userinterface for submitting reports is also based on question configurationdata. For instance, the report menu adds report links, reports andcharts automatically when new questions are configured.

Report Delivery:

In one embodiment, automated reports have many options for delivery:email subscription, email body, email attachment, SMS notification, RSS,Twitter, document management system post, paper, web service, SFTP, EDI,HTTPS, Excel, XML or other file format. In another embodiment, reportsare sent manually by email or mail.

Reports are used by various persons in the organization (e.g. partnermanagers, domain experts, project managers). In addition, select reportsare made available to the partners (e.g. a report of the questions andtheir responses; a report of partner gaps and recommendations). In oneembodiment, reports for partners are made available for each partner inthe FSMT user interface.

9) Support Request Tracking (Support)

In one embodiment, a Support Request Tracking module is used to ensurethat partner questions are answered in a timely fashion for anorganization that make certain personnel available to support some orall partners. Support is configured in the DEFINE step of PCI and thenmainly used in the MEASURE and IMPROVE steps.

Support Request Tracking (Support):

In one embodiment, support software tracks whether team members providetimely answers to partner questions.

In one embodiment, partners go to a website to create a support request.In another embodiment, partners email requests to an email alias whichmultiple people read or to a specified person. In another embodiment,partners email support request to an alias which loads it automaticallyto the Support module as a new Support Request or as an addition to anexisting Support Request. In another embodiment, software enablesself-help support by making a support knowledge base and resolvedsupport cases available to all partners (with confidential data hidden).In one embodiment, the ability to request support and search theknowledge database and Frequently Asked Questions is integrated intoFSMT.

In another embodiment, the organization responds to emailed supportrequests/questions from partners, without a formal support softwaremodule.

10) Business Continuity Management (BCM) or other Domain-Specific Module

In one embodiment, it is not necessary to have a domain-specific modulebecause the FSMT module and related modules are flexible enough toaccommodate all domain-specific needs. In another embodiment, there arelimitations in the types of information that FSMT supports. In thisembodiment, a separate domain-specific module is added for suchinformation. In one embodiment, the modules described above integratewith existing, legacy, domain software modules. In one embodiment, thedomain-specific module is integrated into the User Interface of FSMTsuch that the partner does not perceive a difference from a UserInterface standpoint. In another embodiment, the domain-specific modulehas a separate User Interface. In one embodiment, a domain-specificmodule is used in the same PCI steps as the FSMT module.

Business Continuity Management (BCM):

A domain-specific module for BCM is described in this document toillustrate an example of a domain-specific module,

In one embodiment, this is a Web-based, software module that collectsand validates partner business continuity data (e.g. subcontractorsites, critical service providers, alternate site recover plans andrecovery time estimates for key sites, parts, site activities and partactivities.). In another embodiment, this is a software module that aidspartners in creating BCM process documents.

In one embodiment, the user interface of the BCM module is integratedwith the user interface of the FSMT module so that suppliers need tocomplete just one survey to provide the data required by both modules.In another embodiment, the BCM module (or other domain-specific module)could be integrated with any of the other modules.

Other Domain-Specific Module:

In another embodiment, a domain-specific module is implemented for otherdomains. FIG. 12 lists Country of Origin, EU RoHS, Lead-Free and SocialResponsibility as examples of other domains. These are just a subset ofthe potential domains. For example, other domains include environment,health, safety, security and quality.

In another embodiment, there would be no domain-specific module.Instead, all domain-specific questions are incorporated into the FSMTand related modules.

IT Data Storage

In different embodiments, different IT applications can differ in howthey store they data relevant at each step of PC I. Data storage may beimplemented in many different types of applications includingcustom-built transactional database systems, custom-built datawarehouses, office productivity applications, applications hosted byvendors, vendor applications installed in-house, custom-builtapplications; email survey tools, web-based survey tools, outsourcedservice providers, etc. In one embodiment, the whole PCI methodology maybe implemented in one such application while in other embodimentsdifferent ones of these applications and storage may be mixed andmatched for a project. In another embodiment, part of the PCI method issupported by IT while other parts have limited or no automation.

There are many ways to store partner information that is gathered forthe System and Method for Managing Partners. One approach is to use adatabase, such as Microsoft SQL Server, Oracle, IBM DB2, My SQL,Microsoft Access, etc. This is particularly useful in embodiments of PCIthat entail many partners. Another embodiment with say, just a coupledozen partners may use office productivity applications such asspreadsheets and word processing documents.

FIGS. 14a-14e provide an example of data content and structure in oneembodiment of an initiative. It is meant as just one example of anembodiment of data storage. An advanced example was chosen to illustratemore kinds of data and insights than possible with a smaller data store.Another embodiment could have a portion of similar data in far fewertables. A different embodiment might add even more tables to getadditional insights into partner capabilities, to achieve additionalimprovement objectives or to add domain-specific data elements.

Keep in mind that the same kinds of data described for the tables belowcan be implemented in other types of applications and storage besidesdatabases. For example, similar data can be stored in spreadsheet tabs,rows and columns in a different embodiment. For example, an embodimentmay use spreadsheets to store hazardous materials use and controls whilealso storing partner information about social responsibility. In anotherembodiment, separate word processing documents may be sent out to eachpartner to gather information. In another embodiment, electronic surveytools and websites may be used to gather and analyze partnercapabilities.

The important point is that the System may be implemented in many ways.The following section describes one such embodiment and is illustratedby FIGS. 14a-14e, 15a-15f and 16.

FIGS. 14a-14e show the Integrated Entity Relationship Diagram (ERD) forone embodiment of storage that supports the System. FIG. 14 lists thetables, table identifiers, relationships to other tables (i.e. foreignkeys) and the cardinality of the relationship (e.g. one to many, many tomany, etc.).

The following group of tables in FIGS. 14a-14e store system users andtheir access rights as part of one embodiment of a SecurityAdministration, Data Management & Transfer (ADM) module:

-   -   aspnet_Applications        -   Stores the list of applications. An application is a            grouping of sets of features    -   aspnet_Membership        -   Stores user logins and encrypted passwords    -   aspnet_Users        -   Stores the user/application relationship    -   aspnet_Roles        -   Stores application roles, which are related to a subset of            features.    -   In this embodiment, the roles are partner (this role is used to        restrict user to seeing only the information related to the        partner's own organization), reviewer (can view and edit all        partners but cannot change system configuration) and        administrator (complete access). All the teams in PCI may be        assigned one or more of these roles    -   In another embodiment, more roles could be defined in order to        have more fine-grained control. For instance, a new role could        be created for the Campaign Team to allow them to see all        partners data but not edit them

In another embodiment, there could be just two roles: partner andadministrator

-   -   aspnet_UsersinRoles        -   the set of roles for a user    -   SYS_USER        -   Stores the relationship between contacts and aspnet_Users.            If a contact is not in this table, he or she cannot log in.            This feature allows a contact to be entered into a system            without allowing the contact to have access to the system

A variation of this embodiment could have all the tables above exceptfor SYS_USER. In this case, any contact would be allowed to use thesystem.

Another embodiment would have neither aspnet_Applications noraspnet_Users. In such an embodiment, the assumption is that there isjust one application for any user.

Another embodiment could combine the aspnet_Membership and aspnet_Userstables into one table that stores logins, passwords and users. Nofunctionality would be lost in this case.

Another embodiment could have just two tables: one for userlogins/passwords and other for roles.

The following tables store general information about partners. In oneembodiment, these tables include both domain-specific data (e.g. Time toRecover a site after a disaster, which applies to the BusinessContinuity domain) as well as data that is useful across multipledomains (e.g. partner site address). Note: The embodiment shown belowwas initially for supplier management and then applied to partners ingeneral. Therefore some tables holding partner information have“SUPPLIER” in their name. In another embodiment, “PARTNER” issubstituted for “SUPPLIER” in table names in order to indicate that thetable is used for all kinds of partners, not just suppliers. Thisconcept applies to all tables and other data schema objects described inthis document that have “SUPPLIER” as part of their name:

-   -   CONTACT        -   Stores records for people who have been entered into the            list of contacts for some partner    -   PART        -   The list of products or services that the organization            purchases from suppliers or other partners    -   SITE        -   The list of partner locations (e.g. manufacturing plant            locations)    -   DOCUMENT        -   Stores all the documents uploaded by partners    -   SUPPLIER        -   Stores the list of valid suppliers (or partners in general)            to the organization.    -   SUPPLIER_CONTACT        -   Allows a contact to be related to more than one partner. For            instance, a manufacturer's rep may represent more than one            partner    -   SUPPLIER_DOCUMENT        -   Stores the relationship that ties a particular DOCUMENT file            to a particular partner.    -   SUPPLIER_PART        -   Stores the relationship that ties a particular PART record            to a particular partner. For example, this allows the system            to list the products or services that the partner sells to            the organization    -   SITE_PART        -   Stores which parts are produced at which sites by the            partner. In one embodiment, this information is used for            improving Country of Origin compliance. In another            embodiment, this table is used to gather part-level recovery            information for Business Continuity; In a more general            embodiment, this table is called PARTNER PRODUCT OR SERVICE,            and may include many types of parts, materials, services,            etc. that different types of partners provide    -   SITE_ALT        -   Stores alternate site information for a production site. In            one embodiment, this information is used to determine which            other sites may be used to recover a destroyed production            site in a PCI effort focused on Business Continuity.    -   CYCLE        -   Stores the name of the current PCI effort and its start and            end date        -   This table can be related to partner measures and objectives            to store trends over time    -   DOMAIN        -   Stores the subject areas of the capabilities that are            measured and improved by PCI. For example, business            continuity, quality, etc.    -   SUPPLIER_TYPE_DOMAIN        -   Relates DOMAIN and SUPPLIER_TYPE so that all the suppliers            in certain supplier types will be measured as part of a PCI            cross-domain improvement effort

While one embodiment may store data similar to that stored in all thetables above, another embodiment may store only “SUPPLIER” (or“PARTNER”) information. In this case, data would be gathered for thepartner as a whole and there would be no lower level of detail aboutparts, sites, etc. for a partner. In this case, information for thepartner contact might be stored the “SUPPLIER” (or “PARTNER”) table sothat there would be a person in the database who could be contacted forthe partner.

Another embodiment could add CYCLE in order to be able to compare trendsover time.

Another embodiment could add SUPPLIER_TYPE_DOMAIN (orPARTNER_TYPE_DOMAIN) and DOMAIN in order to apply PCI to some partnersbut not others for a certain domain. For example, transportation serviceproviders are not included in the lead-free improvement initiative.

Another embodiment could add “CONTACT” and “SUPPLIER_CONTACT” as well inorder to store contact information for multiple people who work at thepartner.

Another embodiment could add “DOCUMENT” and “SUPPLIER_CONTACT”management to “SUPPLIER” in order to enable the partner to uploaddocuments such as policies, procedures and plans.

Another embodiment could have SUPPLIER, CONTACT, SUPPLIER_CONTACT, SITEand SUPPLIER SITE in order to store information about multiple locationsfor the partner and multiple contacts as well. For example, onemanufacturing partner might have 4 production sites and 2 contacts andanother partner might have 30 sites and 15 contacts.

Another embodiment could add PART and SUPPLIER_PART as well in order toask the partner about information for critical parts that the partnerprovides to the organization.

In one embodiment, the following tables are important for definingobjectives and measuring current partner capabilities (FSMT module):

-   -   SURVEY        -   List of all surveys. There may be more than one survey at            one point in time in the past, present or scheduled for the            future    -   SUPPLIER SURVEY        -   List of surveys for one particular partner. A survey may be            required of a subset or all partners    -   SURVEY ITEM        -   Question or other capability area. Link to supplier, site,            part, contact, etc. as needed    -   SURVEY_ITEM_CONTROL        -   User interface control for question (e.g. drop down box)    -   SURVEY_LIST        -   List of values name    -   SURVEY_ITEM_RULE        -   Validation dependency between questions (e.g. if the answer            to question 1 is Yes, then question 6 is optional)    -   SURVEY_ITEM_RULE TYPE        -   Validation type (e.g. required/optional)    -   SURVEY_ITEM_TYPE        -   Data type for validation (e.g. number, text, integer)    -   SURVEY_ITEM_VALUE        -   Full individual list of values for question

In one embodiment, the following tables are important for identifyinggaps, reviewing partner capabilities and tracking partner gap history(GIRT module) and for scoring and rating partners (SCORE module).

-   -   SUPPLIER_SURVEY_ITEM        -   Supplier fact (e.g. actual response to a specific question),            gap, reference, associated points    -   SUPPLIER_SURVEY_ITEM COMPLETENESS        -   Question event history (e.g. when opened, closed, etc.)    -   SUPPLIER_SURVEY_ITEM EVIDENCE        -   Documents uploaded by the partner to support a claimed            capability

In one embodiment, system 100 uses a completely different set of tablesfor defining objectives and identifying partner gaps. This embodiment isdescribed below by the tables prefixed by “OBJECTIVE_”. This differentembodiment illustrates that there are many possible embodiments of aSystem and Method to Manage Partners. For example, in one embodiment,the following tables are used to define objectives:

-   -   OBJECTIVE        -   Stores the objective name and other basic information    -   OBJECTIVE_DOMAIN        -   Allows objectives to be grouped into a domain, such as            business continuity or hazardous substances    -   OBJECTIVE_RULE        -   Stores the comparison for the objective. For example, a rule            record could store something to the effect that recovery at            an alternate site must take no longer than a number that is            stored in the related    -   OBJECTIVE_THRESHOLD        -   Stores the number to which the rule is compared. For            example, 4. So, the rule and threshold together make a            standard such as recovery at an alternate site must take no            longer than 4 weeks.

In one embodiment, system 100 uses a single objective table to store theobjective. Another embodiment could have the RULE and THRESHOLD storedin a single table.

In one embodiment, system 100 adds an OBJECTIVE CYCLE table to store thedeadline for the objective for the campaign cycle. Without this table,the end date that is stored in the CYCLE table could be used as thedeadline for every objective.

In one embodiment, system 100 stores the objectives in the software code(i.e. “hard coding”) instead of using tables. Another embodiment may usespreadsheets and other files to store objectives, gaps, etc.

Once the basic definition for objectives is stored as described above,objectives may be applied to any number of supplier-related (orpartner-related) tables in order to apply the objective to theappropriate capabilities of the partner organizations.

For example, in one embodiment, the objective is applied to the partneras a whole. A table like OBJECTIVE_SUPPLIER (or OBJECTIVE_PARTNER) maybe used for that. In the same embodiment, there may be objectives thatare applied to all the partner's sites using a table like OBJECTIVESITE. In the same embodiment, there may be other objectives that mayapply to all partners of a certain supplier type category so anOBJECTIVE_SUPPLIER_TYPE (OR OBJECTIVE_PARTNER_TYPE) table is added forthat.

-   -   OBJECTIVE_SUPPLIER        -   Stores objectives that are applied to all partners as a            whole    -   OBJECTIVE_SITE        -   Stores objectives that are applied to all the sites of each            partner    -   OBJECTIVE_SUPPLIER_TYPE        -   Stores objectives that are applied to all the sites of each            partner

Other embodiments may include objectives linked to other tables in thedata model. For example:

-   -   OBJECTIVE_PART    -   OBJECTIVE_DOCUMENT    -   OBJECTIVE_CONTACT_ROLE    -   OBJECTIVE_SITE_ACTIVITY_TYPE

Business rules determined in the PCI “IMPROVE” step are used to applythe objectives defined in the tables above to partners. For example, oneembodiment may have a business rule that says that all partner sitesmust pass the objective in the OBJECTIVE_SITE table. Another embodimentmight use a different business rule that says that a partner is OK ifany of the partner's sites is OK.

Additional tables may be added to a data model in order to measure andreport current capabilities in different ways. For example, theembodiment of PCI illustrated in FIGS. 14a-14e also includes thefollowing tables:

-   -   COUNTRY        -   List of all the countries in the world. This is useful in            storing a main headquarters address for the partner, site,            and/or contact    -   BUSINESS_UNIT        -   List of the organization's business units, for organizations            with multiple divisions or subsidiaries    -   SUPPLIER_BUSINESS-UNIT        -   Stores which of the organization's business units are served            by the partner    -   SUPPLIER_TYPE        -   Classifies a partner, often based on the classes of products            and services provided. Stores a list of classifications for            the partner. For example, a list of Standard Industry            Classifications may be stored here or the organization may            use its own classification scheme    -   SUPPLIER_SUPPLIER_TYPE        -   Stores the classifications that a particular partner belongs            to    -   SUPPLIER_TYPE_DOCUMENT        -   If different classes of partners should be given different            document templates to complete, this table can store            different document templates for different partner types in            case the organization requires that partners be given            document templates to complete

While the embodiment of FIGS. 14a-14e shows one set of tables, in oneembodiment, system 100 implements the objectives, current capabilitiesand gaps though a different data storage schema. Another embodiment mayhave objectives that are so simple that tables are not needed to storethem (e.g. they could be coded into business rules or reports). In oneembodiment, system 100 includes “SUPPLIER_TYPE” tables, especially ifmeasures and objectives are expected to vary by partner type, but notthe objectives tables. In one embodiment, system 100 uses theBUSINESS_UNIT tables in case the organization wants to establishdifferent measures and/or objectives for each of the organization'sbusiness units.

In one embodiment, system 100 uses tables added to enable certain datato be entered offline, such as in spreadsheets or in another system, andthen allow that data to be imported. For example, the following tablesmight be used to import parts data about sites from an offline datasource:

-   -   SITE_PART_IMPORT    -   SITE_PART_IMPORT_BATCH

In one embodiment, workflow statuses may be contained in the softwarecode (i.e. “hard-coded”). In another embodiment, putting workflowsequences and statuses in tables can add flexibility. For example, thefollowing tables may be used to store workflow and approval information:

-   -   WORKFLOW    -   SUPPLIER_WORKFLOW    -   SUPPLIER_APPROVAL    -   SITE_APPROVAL

Organizations may request that the partner provide information about thepartner's critical partners. In one embodiment, all the tables in FIGS.14a-14e that contain “SUBCOMPONENT” in their name are used to storeinformation about suppliers' suppliers of critical subcomponents orservices. For example, the SUBCOMPONENT table can list different kindsof materials or parts in short supply (e.g. Silicon may be in a recordin table SUBCOMPONENT). Then the supplier may be asked who manufacturesthe silicon that they purchase, where it is manufactured (SITESUBCOMPONENT can store information about where the silicon suppliermakes the silicon), etc. Knowing the location of suppliers' suppliersthat make items in short supply can help to uncover risky situationswhere many suppliers get the same material or part from a commonsupplier.

Other tables in the embodiment pictured in FIGS. 14a-14e include thefollowing (note: different embodiments may include no similar tables ormore than one similar table):

-   -   SYS_CONFIG        -   Stores system-wide settings    -   CONTACT_REQUEST        -   Stores requests from partners to establish a login and            password. Such a request requires administrator approval    -   CONTACT_ROLE        -   Contact's responsibilities at the partner. For example,            business continuity contacts, Country of Origin contact,            etc.    -   CONTENT_TYPE        -   Document file type (e.g. spreadsheet)    -   SITE_CONTACT        -   The key partner contact for a partner site for a certain            domain (e.g. emergency contact for business continuity)    -   SITE_DOCUMENT        -   Stores the fact that an uploaded document is related to a            particular site or sites    -   SYS_MESSAGE        -   Stores all the application's error messages, warning            messages and informational messages

FIGS. 15a-15f list business rules for the same embodiment of PCI asshown in FIGS. 14a-14e . In FIGS. 15a-15f , the “Procedure” headinglists stored procedures that contain the most complex business rules forvalidation and updates. Many of the names are self-explanatory since thenaming convention followed in FIG. 13 includes both the main table namethat is impacted as well as the action taken on that table. In addition,the key parameters passed to the stored procedure follow the word “BY”in this naming convention. For example:

-   -   CONTACT_INSERT    -   EXPORT_CONTACT_DATA    -   CONTACT_SELECT_BY_ID        -   selects contact information when it is passed a contact ID            as a parameter

In addition to the “Procedure” business rules at the start of FIGS.15a-15f , FIGS. 15a-15f also list additional business rules listed under“Table Functions” and “Functions”. These business rules select data,generally for online forms, exports or reports. They follow a similarnaming convention to identify the main table from which they selectdata.

There are hundreds of tables and business rules included in FIGS.14a-14e, 15a-15f and 16. Another embodiment could have far more tablesto hold additional information that used to measure and improve partnercapabilities. A different embodiment could have far less.

IT Reporting and Analysis

In one embodiment, reports on partner status are generated from thetransaction database while additional analysis is facilitated byexporting data into CSV format for import into a spreadsheet foranalysis using filters, statistics, pivot tables and pivot charts.

In one embodiment, system 100 data from the transaction database isimported into a data warehouse in order to execute standard reports,create ad hoc reports, perform business intelligence analysis and datamining. The data warehouse for one such embodiment is illustrated inFIG. 16. FIG. 16 reformats key information from the tables embodied inFIG. 14 into a data warehouse star schema to facilitate rich slicing anddicing. In one embodiment of the data warehouse concept, a datawarehouse Business Intelligence, ad hoc reporting and data mining toolsuch as Business Objects is used. In another embodiment, a datawarehouse function performs metrics and gaps calculations and thenexports the results in .CSV format. End users use filters, Excel pivottables and pivot charts to slice and dice the data.

Note: the table naming convention is different for a start schema. In astar schema, the standard table naming convention prefixes the maintables containing numbers by the word FACT. Attribute tables related tothose FACTs are prefixed by DIM_, which stands “dimension” of a fact.

In sum, IT processing, storage and reporting may be implemented in manyways including database systems, office productivity applications,applications hosted by vendors, vendor applications installed in-house,custom-built applications, email survey tools, web-based survey tools,outsourced service providers, data warehouses, etc. The whole System andMethod for Managing Partners may be embodied by one or more of thesetools and associated with different types of storage in differentembodiments. Domain inputs to IT and the PCI methodology are isolated tomake it easier to apply to any domain. The result is a flexible regimenfor effecting measurable improvements in the capabilities of partnerorganizations.

In the above, portions of the system can be distributed as computer codeon articles comprising computer readable media. Examples of articlescomprising computer readable media are floppy disks, hard drives, CD-ROMor DVD media or any other read-write or read-only memory device.

Portions of the above description have been presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the ways used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of steps leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers, or the like. It should be borne in mind, however, thatall of these and similar terms are to be associated with the appropriatephysical quantities and are merely convenient labels applied to thesequantities. Unless specifically stated otherwise as apparent from thefollowing discussions, terms such as “processing” or “computing” or“calculating” or “determining” or “displaying” or the like, refer to theaction and processes of a computer system, or similar computing device,that manipulates and transforms data represented as physical (e.g.,electronic) quantities within the computer system=s registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission or display devices.

Although specific embodiments have been illustrated and describedherein, it will be appreciated by those of ordinary skill in the artthat any arrangement which is calculated to achieve the same purpose maybe substituted for the specific embodiment shown. This application isintended to cover any adaptations or variations of the presentinvention. Therefore, it is intended that this invention be limited onlyby the claims and the equivalents thereof.

1. A method, comprising: establishing a database on a databasemanagement system, the database management system connected to anetwork, wherein the database includes a plurality of database records,each database record associated with one of a plurality of separatebusiness organizations, each record including values, at a given pointin time and for the respective business organization, of some or all ofthe quantitative and qualitative data associated with financial risk,wherein the database management system includes a database schema usedto define how the records are stored in the database; associating one ormore users with each business organization, wherein associating includesauthenticating the user and creating permissions that provide the userwith remote access over the network to the records of the user'sorganization in the database while preventing access to the recordsstored in the database that are associated with one or more of the otherbusiness organizations in the plurality of business organizations;storing, within a computer connected through the network to the databasemanagement system, a financial risk prediction model, the financial riskprediction model based on quantitative and qualitative data associatedwith financial risk for business organizations; assessing financial riskfor each of the plurality of business organizations by applyingapproximately concurrent in time values of the quantitative andqualitative data stored in records of the database to the financial riskprediction model; monitoring the financial risk for each of theplurality of business organizations over a period of time, whereinmonitoring includes: receiving, from one of the users, at the databasemanagement system, over the network and at various times over the periodof time, qualitative data associated with financial risk for one of theplurality of business organizations, wherein receiving qualitative dataincludes authenticating the user submitting the qualitative data toensure the user has permission to modify records associated with therespective business organization; validating the qualitative data,wherein validating includes sending an error message to the respectiveuser over the network if corrections are needed; storing the validatedqualitative data to a database record of the business organization ifthe user has permission to modify records of the respective businessorganization; receiving, at the database management system and from asource connected to the network, quantitative data approximatelyconcurrent with the received qualitative data, the received quantitativedata associated with financial risk for one of the plurality of businessorganizations, wherein the information received is in a non-standardizedformat; updating the respective record based on the receivedquantitative data, wherein updating includes validating the informationand storing the validated information to the respective record; andapplying the received current values of the quantitative and qualitativedata for the business organization to the financial risk predictionmodel to assess financial risk; and reporting the financial risk for thebusiness organization.
 2. The method of claim 1, wherein financial riskincludes one or more of credit risk and bankruptcy risk.
 3. The methodof claim 1, wherein reporting includes reporting, in real-time, when thefinancial risk for the business organization is greater than a financialrisk threshold.
 4. The method of claim 1, wherein receiving quantitativedata includes receiving quantitative data in a non-standardized format;and wherein updating the respective record based on the receivedquantitative data further includes converting the information receivedin the non-standardized format to a standardized format.
 5. The methodof claim 1, wherein some or all the quantitative data includes thirdparty ratings for the business organization.
 6. The method of claim 1,wherein the quantitative data includes financial market data for thebusiness organization.
 7. The method of claim 1, wherein reportingincludes one or more of: notifying one or more other businessorganizations of business continuity risk associated with the monitoredbusiness organization; describing factors behind the financial riskassessment; suggesting to the monitored business organization ways toreduce financial risks; and suggesting ways to limit the risk associatedwith doing business with the monitored business organization.
 8. Amethod, comprising: establishing a database on a database managementsystem, the database management system connected to a network, whereinthe database includes a plurality of database records, each databaserecord associated with one of a plurality of separate businessorganizations, each record including values, at a given point in timeand for the respective business organization, of some or all of thequalitative and quantitative data associated with financial risk,wherein the database management system includes a database schema usedto define how the records are stored in the database; associating one ormore users with each business organization, wherein associating includesauthenticating the user and creating permissions that provide the userwith remote access over the network to the records of the user'sorganization in the database while preventing access to the recordsstored in the database that are associated with one or more of the otherbusiness organizations in the plurality of business organizations;storing, within a computer connected through the network to the databasemanagement system, a financial risk predication model, the financialrisk prediction model based on qualitative and quantitative dataassociated with financial risk for business organizations; receivingcurrent values of some or all of the qualitative and quantitative datafor a business organization from one or more sources connected to thenetwork; applying the received current values to the financial riskprediction model to assess financial risks for the businessorganization; and monitoring the financial risks associated with thebusiness organization over time, wherein monitoring includes: receivingapproximately concurrent values of the qualitative and quantitative datafor the business organization from a source connected to the networkduring the monitoring time; applying the received approximatelyconcurrent values of the qualitative and quantitative data for thebusiness organization to the financial risk prediction model to assessfinancial risks associated with the business organization; andreporting, to another business organization and across the network, thefinancial risks associated with the business organization.
 9. The methodof claim 8, wherein financial risk includes one or more of credit riskand bankruptcy risk.
 10. The method of claim 8, wherein reportingincludes reporting, in real-time, when the financial risk for thebusiness organization is greater than a financial risk threshold. 11.The method of claim 8, wherein the quantitative data includes one ormore of third party ratings and number of late payments.
 12. The methodof claim 8, wherein the quantitative data includes financial market datafor the business organization.
 13. The method of claim 12, wherein thefinancial market data includes bond information.
 14. The method of claim8, wherein the quantitative data includes information from one or morefinancial statements of the business organization.
 15. The method ofclaim 8, wherein receiving approximately concurrent values of thequalitative and quantitative data includes receiving some or all of thequantitative data in a non-standardized format; and wherein updating therespective record based on the received quantitative data furtherincludes converting the information received in the non-standardizedformat to a standardized format.
 16. The method of claim 8, whereinreporting includes one or more of: notifying one or more other businessorganizations of business continuity risk associated with the monitoredbusiness organization; describing factors behind the financial riskassessment; suggesting to the monitored business organization ways toreduce financial risks; and suggesting ways to limit the risk associatedwith doing business with the monitored business organization.
 17. Themethod of claim 8, wherein reporting includes displaying a graph, thegraph depicting bankruptcy risk.
 18. A system comprising: memory; and aprocessor connected to the memory; wherein the memory includesinstructions that, when executed by the processor: establishes adatabase on a database management system, the database management systemconnected to a network, wherein the database includes a plurality ofdatabase records, each database record associated with one of aplurality of separate business organizations, each record includingvalues, at a given point in time and for the respective businessorganization, of some or all of the qualitative and quantitative dataassociated with financial risk, wherein the database management systemincludes a database schema used to define how the records are stored inthe database; associates one or more users with each businessorganization, wherein associating includes authenticating the user andcreating permissions that provide the user with remote access over anetwork to the records of the user's organization in the database whilepreventing access to the records stored in the database that areassociated with one or more of the other business organizations in theplurality of business organizations; stores, in the memory, a financialrisk prediction model, the financial risk prediction model based onqualitative and quantitative data associated with financial risk forbusiness organizations; receives current values of some or all of thequalitative and quantitative data for a business organization; appliesthe received current values to the financial risk prediction model toassess financial risks for the business organization; monitors thefinancial risks associated with the business organization over time,wherein monitoring includes: receiving approximately concurrent valuesof the qualitative and quantitative data for the business organizationduring the monitoring time; and applying the received concurrent valuesof the identified qualitative and quantitative data for the businessorganization to the financial risk prediction model to assess financialrisks associated with the business organization; and reports thefinancial risks associated with the business organization.
 19. Thesystem of claim 18, wherein financial risk includes one or more ofcredit risk and bankruptcy risk.
 20. The system of claim 18, whereinreporting includes displaying a graph, the graph depicting bankruptcyrisk.